Shareware Grab Bag/Shareware Grab Bag.iso/007/netlangc.arc/NETLANG.C

C/C++ Source or Header | 1985-09-05 | 159.4 KB | 4,187 lines

Article 4303 (653 more) in net.lang.c:
From: [e-mail] (CTD_STUDENT0.)
Subject: Re: Structure question (problem)
Message-ID: <[e-mail]>
Date: 23 May 85 12:59:40 GMT
Date-Received: 26 May 85 07:14:55 GMT
References: <[e-mail]>
Organization: AT&T Bell Laboratories
Lines: 44

--MORE--(34%)> Could someone please inform me what the hell I am doing wrong.  The
> subject is auto-initialization of structures.  Here is a simple program
> that trys to initialize the stucture, and the associated error
> message.  If I take one of K&R's examples (pg 124, last half page),
> I get the same error.
> BTW-This is 4.2bsd.
>
> =====
>
> /* Structure test */
>
> #include <stdio.h>
>
>
> main() {
>
>       static char *text[] = { "Fred", "Wilma", "Barney", "Betty" };
>       struct l {
>               int a;
>               int b;
>               char *c;
>               int d;
>                } e = { 0, 1, text[0], 4 };
>
>       printf("Fred is married to Wilma, Barney to Betty...\n");
>
> }
>
> =====
> % cc t.c
> "t.c", line 14: no automatic aggregate initialization
> "t.c", line 14: warning: illegal combination of pointer and integer, op =
>
Aggregates (arrays, structures, unions) can only be initialized if
they are declared static or external. A simple:

        static struct l{ .........

will do.

--

Fred Eng
AT&T Bell Laboratories
(Mail) End of article 4303 (of 4956)--what next? [npq]

Article 4436 (520 more) in net.lang.c:
From: [e-mail] (Landon Noll)
Subject: Re: 2nd Annual Obfuscated Contest Winners
Message-ID: <[e-mail]>
Date: 29 Jun 85 04:53:13 GMT
Date-Received: 4 Jul 85 05:49:40 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Landon Noll)
Distribution: net
Organization: Rational Swamiconductor, Sanivale
Lines: 29
Keywords: precedence
Summary:

--MORE--(31%)In article <[e-mail]> [e-mail] (Morris M. Keesan) writes:
 >1. The most obscure program:
 >(submitted by Lennart Augustsson <seismo!mcvax!enea!chalmers!augustss> )
 >
 >is not legal C, even though the 4.2BSD compiler (and presumably other PCC-based
 >compilers) processes it as the author apparently intended.
 >
 >For these two reasons, especially the first, I don't think this program
 >deserves a prize.  Also, this is a bug in the 4.2BSD compiler, and even more
 >so in the 4.2BSD lint, which should issue a warning even if the compiler is
 >being forgiving.

So it breaks on other compilers eh?  Well such is life with a Obfuscated C
contest!  One has to hand it to someone for finding a "hole" in a compiler,
and driving a truck through it.

The contest rules stated that it has to be in "Common C".  There was nothing
to point out that it HAD to be standard C, K&R C, or Deathstar Unix C.
The ability to run an entry on other systems was a plus, not a rule.  Also,
we did not try, nor did we intend to check out each program on every
system/compiler.  We did not have time, or resources to do so!

Thank you for posting a suggested change so that other people might see
what the program does.   If anyone else finds another porting problem,
you might consider posting a bug fix to net.sources.bugs.

chongo <in any event, the awards are final> /\../\
--
no comment is a comment.
(Mail) End of article 4436 (of 4956)--what next? [npq]

Article 4718 (238 more) in net.lang.c:
From: [e-mail] (Chris Shaw)
Subject: Re: "writing code"
Message-ID: <[e-mail]>
Date: 26 Jul 85 07:23:08 GMT
Date-Received: 3 Aug 85 17:22:00 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Chris Shaw)
Organization: U of Waterloo, Ontario
Lines: 36

--MORE--(28%)>General question: does anybody "write code" on paper first any more?
>--
>Ed Nather


For me, there is a choice: write it twice (on paper then on screen),
or write it once (on screen only).

However, it isn't as hard-and-fast as that. This only truly works for
simple stuff. For hard programs, I use paper for "getting the algorithm
into my head". Recently, for example, I had to do a complicated data structure
conversion. The result was terrifically simple, but the core of the
thing was a...
                x[ --b[ x[ --b[i] ] ] ] = i ;

..kind of affair, which required a lot of thought, and had to be designed
with pictures of linked data structures, etc. etc.

The point of all this is that the tools called "paper & pencil" are
inadequate for designing programs at the textual level, because line
insertion is improbable, and looks like hell if you do more than a little.

Drawing pictures with pencil is easy, though, and impossible on your
normal terminal. If I had access to a good graphics package, one with real
flexibility & "definable actions", then I'd drop paper altogether for design.

The conclusion is that this is really an ergonomics issue (if I take the
meaning correctly). Tools that are completely satisfactory/comfortable
will displace those that aren't.


Chris Shaw    watmath!watmum!cdshaw  or  cdshaw@watmath
University of Waterloo

Work is the curse of the drinking classes.
                - Oscar Wilde
(Mail) End of article 4718 (of 4956)--what next? [npq]

Article 4719 (237 more) in net.lang.c:
From: [e-mail] (Guy Harris)
Subject: Re: c programming style - READ THIS
Message-ID: <[e-mail]>
Date: 26 Jul 85 07:35:37 GMT
Date-Received: 3 Aug 85 17:32:55 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Sun Microsystems, Inc.
Lines: 47

--MORE--(19%)> I use C largely because it DOES allow (encourage?) me to
> think in terms of the underlying bit patterns involved.  I
> pay very close attention to just what is happening to
> pointers when they are changed; that is the price I pay for
> fast running programs.

But is this a case of "thinking of the underlying bit patterns", or is it a
case of thinking of the underlying operations on an abstract machine?  I.e.,
do you think of a pointer as a natural number indexing a large array which
is your process' address space (which may not work on a segmented machine!),
or do you think of it as something that points to an object?  You can still
think in the latter terms without forgetting the important part of how
pointers are implemented - i.e., I doubt the ability to cast pointers to
some integral type and back again is needed, in general, for efficiency

> When I AM concerned with performance, I have to put in the
> effort to track every pointer on my own, and all the other
> neat stuff C lets me do without PASCAL or ForTran style
> run-time checking.

What do you mean by "track every pointer on (your) own"?  True, you can't
use pointers in FORTRAN without run-time checking, but then you can't use
pointers in FORTRAN *with* run-time checking, since it doesn't *have*
pointers.  FORTRAN doesn't do much "run-time checking" because it doesn't
have much checking to do - no pointers, so no null-pointer checking; no
subrange or enumerated types, so no checking assignments to such types.  I
believe there are many PASCAL compilers that will allow you to turn the
checking off - of course, if you do so, you should have good reason to be
sure the errors that the checking would detect should occur, considering
that those errors can bomb your program regardless of whether it was written
in PASCAL or C.  (For instance, if you get a pointer from a routine which
could return a null pointer, *always* check it before using it unless you
*know* that the particular call to that routine which returns the pointer
won't return a null pointer.  And make *sure* you really "know" it.  Just
because you created a file "/tmp/foo" and made it readable doesn't mean
'fopen("/tmp/foo", "r")' is not going to return NULL - you could get an I/O
error, or somebody else could have unlinked the file while you weren't
looking, or...)


You don't have to think of pointers as integers indexing a large array which
is your address space (and think of null pointers as being the integer 0) in
order to write efficient C code.  (And if you do think that way, what you
may end up with is C code that will break when somebody else tries to run it
on their machine - which will force *them* to fix the problem.)

        Guy Harris
(Mail) End of article 4719 (of 4956)--what next? [npq]

Article 4720 (236 more) in net.lang.c:
From: agt@pucc-k (Kevin Braunsdorf)
Subject: Inconsistency in Style -> Unreadable Code
Message-ID: <1207@pucc-k>
Date: 26 Jul 85 21:26:56 GMT
Date-Received: 3 Aug 85 17:34:10 GMT
References: work at PUCC
Organization: Solon Aquilla's Magic & Art Gallery
Lines: 35

--MORE--(42%)
    All: I am a Computing Center Consultant at Purdue so I see more
different styles of coding per week than most programmers do in a year:
in my view the only bad style is an inconsistent one, eg:

        kp = ++i * j;
        j += 1;

        should be any of:
        i++;                    i += 1;         kp = ++i * j++;
        kp = i * j;             kp = i * j;
        j++;                    j += 1;

        or even:
        kp = (i += 1) * j;
        j += 1;

    Anything that I can notice a set pattern to will help me read the code:
as to the formatting of the code, I personally use
        while (exp) {
            ...
        }       /* line close curly with while  */
    but
        while (exp) {
            ...
            }   /* indent curly too             */
    works for me too, as long as
        fnx()
            {
            ...
            }
    is used too!

                                                :wq
                                                Kevin Braunsdorf
(Mail) End of article 4720 (of 4956)--what next? [npq]

Article 4721 (235 more) in net.lang.c:
From: [e-mail] (Chuq Von Rospach)
Subject: Re: C Programming Style -- New thought  ("writing code")
Message-ID: <[e-mail]>
Date: 27 Jul 85 04:07:36 GMT
Date-Received: 4 Aug 85 00:57:45 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Chuq Von Rospach)
Organization: The Dreamer Fithp
Lines: 13
Summary:

--MORE--(49%)In article <[e-mail]>, [e-mail] (Ed Nather) writes:
>
> General question: does anybody "write code" on paper first any more?

I use paper for any non-trivial design, and usually find myself going
through three or four circuits fleshing it from something resembling
pseudo-code to something resembling C. Even better, when I'm actually in my
office, is my white board -- I don't know how people lived without them.
--
:From the carousel of the autumn carnival:        Chuq Von Rospach
{cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui   nsc![e-mail]

Your fifteen minutes are up. Please step aside!
(Mail) End of article 4721 (of 4956)--what next? [npq]

Article 4723 (233 more) in net.lang.c:
From: [e-mail] (Jon Mauney)
Subject: Re: Style, readability, etc. (use of comments)
Message-ID: <[e-mail]>
Date: 26 Jul 85 15:11:17 GMT
Date-Received: 4 Aug 85 01:13:50 GMT
References: <[e-mail]>, <[e-mail]>
Organization: N.C. State University, Raleigh
Lines: 39

--MORE--(22%)> From: [e-mail] (J. Shapiro)
> Subject: Re: Style, readability, etc. (long, but IMPORTANT)
> Message-ID: <[e-mail]>
>
> > while(ptr++->duck)  /* move pointer to the duck after the next NULL */
> >   ;
>
> This one is even more obscure than the last.  I am a C programmer, and
> this tells me nothing - indeed it is dead wrong, as it simply will not
> happen as the comment might lead me to believe.  This will leave me
> with ptr pointing to the next available record whose element named
> duck is 0.  It certainly has nothing to do with NULL or anything after
> duck.  This is one of the major difficulties with such comments.
> There is a tendency even among experienced programmers to read them
> and believe them, and thereby not see an obvious difficulty.
>
> Jonathan S. Shapiro
> Haverford College
> ..!sjuvax!jss
>

Let me first point out that I agree that block comments are generally
more useful than end-of-line comments.  However, there are many places
in which an end-of-line comment is very useful.  The present example
is one, as proved by the fact that apparently experienced C programmers
cannot agree on the effect of the loop.  Code that is so susceptible to
error should be avoided or heavily commented.

I look at comments as recording the programmer's *intent*, whereas the
code is (obviously) what he actually *did*.  Reading the comments tells
me whether the bug is likely due to a poor design.  If the design
seems sound, then I look for discrepancies between code and comments.
Any such discrepancy is a clear indication of a problem, although the
problem may be as simple as a slip of the mind.  Comments add redundancy
to a program, and redundancy is A Good Thing, in moderation.
--

Jon Mauney,    mcnc!ncsu!mauney       "The door's not shut on my genius, but...
North Carolina State University        I just don't have the time."
(Mail) End of article 4723 (of 4956)--what next? [npq]

Article 4724 (232 more) in net.lang.c:
From: [e-mail] (Chris Torek)
Subject: Re:  C Programming Style -- New thought (\"writing code\")
Message-ID: <[e-mail]>
Date: 26 Jul 85 21:31:08 GMT
Date-Received: 4 Aug 85 02:23:43 GMT
References: <[e-mail]>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 18

--MORE--(47%)>Typing ability probably has a lot to do with [programming on paper]
>to [sic].

Could be; I never write actual code on paper, and I type MUCH faster
than I write (I type reasonably quickly and write excruciatingly
slowly)....

However, I don't think that writing code on paper gains you much
if anything.  The key to writing good code is to have a clear
understanding of the algorithm(s) involved.

In some cases I need to do a complete rewrite after I've got
something working, once I know what I did wrong the first time
around....
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept ([phone])
UUCP:   seismo!umcp-cs!chris
CSNet:  chris@umcp-cs           ARPA:   chris@maryland
(Mail) End of article 4724 (of 4956)--what next? [npq]

Article 4725 (231 more) in net.lang.c:
From: [e-mail] (Arthur David Olson)
Newsgroups: net.unix,net.lang.c
Subject: Re: Portablity using structures and malloc - Help
Message-ID: <[e-mail]>
Date: 27 Jul 85 00:36:19 GMT
Date-Received: 4 Aug 85 02:25:51 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: NIH-LEC, Bethesda, MD
Lines: 13
Summary: bit field vs. char

--MORE--(55%)In article <[e-mail]>, [e-mail] writes:
> An easy way to determine alignment requirements is to take the size
> of a structure containing one character.  Odd-length structures are
> invariably rounded up to convenient units by the compiler.

Or, preferably,
        #define ALIGNMENT (sizeof (struct { char :1;}))
which avoids having to make up a name for a structure element.
--
UNIX is an AT&T Bell Laboratories trademark.
--
        UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie![e-mail]
        DEC, VAX and Elsie are Digital Equipment and Borden trademarks
(Mail) End of article 4725 (of 4956)--what next? [npq]

Article 4726 (230 more) in net.lang.c:
From: [e-mail] (Ed Greenberg)
Subject: Re: C Programming Style -- New thought  ("writing code")
Message-ID: <[e-mail]>
Date: 26 Jul 85 16:16:55 GMT
Date-Received: 4 Aug 85 03:17:03 GMT
References: <[e-mail]> <[e-mail]>
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 15
Summary: composing code on paper

--MORE--(60%)In article <[e-mail]>, [e-mail] (Ed Nather) writes:
>
> General question: does anybody "write code" on paper first any more?
> --

I start to write functions on paper, but you can't use insert
functions on paper!  When I start to stick things in above, I
usually go to the terminal.

I DO write pseudocode on paper though.  Sometimes on index
cards.

                        -edg

{hplabs,dual,ptsfa}!well!micropro!edg
(Mail) End of article 4726 (of 4956)--what next? [npq]

Article 4843 (113 more) in net.lang.c:
From: [e-mail] (Andrew Koenig)
Subject: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 18 Aug 85 15:07:03 GMT
Date-Received: 24 Aug 85 05:29:41 GMT
References: <[e-mail]>
Organization: Bell Labs, Murray Hill
Lines: 17

--MORE--(55%)> int dial(telno)
> char *telno;
> {
>       if(telno){              /*  should be if(*telno)  */
>               dial it;
>       }
>       else{
>               hang up;
>       }
> }

Bob Pierce says that this program failed because it should have been
checking *telno instead of telno.

If telno is NULL, you had better not look at *telno; it's illegal.
If the address of a legal character item is NULL, your compiler is
not implementing the language properly.
(Mail) End of article 4843 (of 4956)--what next? [npq]

Article 4844 (112 more) in net.lang.c:
From: [e-mail] (Guy Harris)
Subject: Re: What is wrong with this program?
Message-ID: <[e-mail]>
Date: 17 Aug 85 03:43:02 GMT
Date-Received: 24 Aug 85 06:17:17 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: net
Organization: Sun Microsystems, Inc.
Lines: 14

--MORE--(55%)>       Not really, you are forgetting that the format "%.8s" will
> cause printf to print up to a null or 8 chars max.  Unfortunately
> this style of printf can not be used with sizeof for compile time
> format changes without run time code support.

True, you can't have the compiler generate the "printf" string, but you can
do

        printf("%.*s", sizeof(thing), thing);

since you can use "*" for a field width or precision and pick up the value
from the argument list.

        Guy Harris
(Mail) End of article 4844 (of 4956)--what next? [npq]

Article 4845 (111 more) in net.lang.c:
From: [e-mail] ( Kevin Long )
Newsgroups: net.bugs.usg,net.lang.c
Subject: Possible bug in VAX 11/750 C compiler
Message-ID: <[e-mail]>
Date: 14 Aug 85 16:20:45 GMT
Date-Received: 24 Aug 85 07:30:38 GMT
Organization: Data Logic Ltd, Greenford, London.
Lines: 51
Xpath: stc stc-a

--MORE--(32%)
    Our company is running system 5.2 on a VAX 11/750 and we have a problem with    our compiler in the area of compile time evaluation of constants.
    The problem has appeared after using the system include file values.h to
    define the value MAXSHORT, the maximum value a short can hold.
    This is defined as follows.

#define BITSPERBYTE     8
#define BITS(type)      (BITSPERBYTE * (int)sizeof(type))
#define HIBITS          ((short)(1 << BITS(short) - 1))
#define MAXSHORT        ((short)~HIBITS)

    After cpp has finished with MAXSHORT it looks like

((short)~((short)(1 << (8 * (int)sizeof(short)) - 1)))

    and the compiler treats this at compile time as -32769; (of some size).
    If we now define

int a = 1;

    Then neither of the following code works as expected

if ( (short) a < MAXSHORT) ....;

if ( a < (int) MAXSHORT) ....;

    The problem is created by the compiler evaluating constants as longs, signed    unless explicitly told to do otherwise, so the problem goes away if short is    changed to unsigned short in the definitions of MAXSHORT and HIBITS above;

    Is this a bug in the compiler or a bad definition in values.h ??
--


                                Klong

The views expressed above are not those of my employer but those of my pet Panda
UUCP: ...!mcvax!ukc!stc!datlog!klong
MAIL: Data Logic Ltd., 320, Ruislip Road East, Greenford, Middlesex, UK.
(Mail) End of article 4845 (of 4956)--what next? [npq]

Article 4846 (110 more) in net.lang.c:
From: [e-mail] (lam)
Subject: Re: how has C bitten you? (and a sidetrack)
Message-ID: <[e-mail]>
Date: 23 Aug 85 10:48:29 GMT
Date-Received: 24 Aug 85 07:31:02 GMT
References: <[e-mail]> <2600011@ccvaxa>
Organization: British Telecom, Ipswich, England
Lines: 34
Xpath: icdoc ivax

--MORE--(32%)[*** The Phantom Article Gobbler Strikes Again ***]
> > >   int i, a[10];
> > >   for (i = 0; i <= 10; i++)
> > >           a[i] = 0;
> > >

> > This looks to me like it will simply overwrite one int's worth of
> > memory beyond the end of the array "a" with the value 0.  Granted,
> > depending on what happens to be after "a", this can have disastrous
> > results, but is there really an implementation in which it will
> > (reliably) lead to infinte looping?
> ----------
> Yes.  Any implementation that allocates the space for i following the
> space for a.

The cause of the infinite loop is due to the storage allocation.
        i.e.    &i == &a[10]
   causing i to be overwritten with 0 when i is 10.

The more interesting thing is that on some compilers, the infinite
   loop does NOT occur.  Lo and behold, the OPTIMISER comes into play.
   If i is put in a Register at the start of the for(), a[10] = 0
   will indeed overwrite i in memory but not the register !!! and the
   loop terminates normally.
   What's worse, the optimiser has in this case hidden a program bug!!!

Thus the moral:

        "Don't just test your code once.  Test it again, this time
         turn the optimiser OFF first".

------------------------------------------------------------------
        Onward Lam
        CAP Group, Reading, England.
(Mail) End of article 4846 (of 4956)--what next? [npq]

Article 4847 (109 more) in net.lang.c:
From: [e-mail] (Bob Peirce)
Subject: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 15 Aug 85 23:24:51 GMT
Date-Received: 24 Aug 85 07:31:23 GMT
Organization: Cookson, Peirce & Co., Pittsburgh, PA
Lines: 26

--MORE--(48%)Here's one that trapped me this week.  It took much head scratching
and debug prints to figure it out.

int dial(telno)
char *telno;
{
        if(telno){              /*  should be if(*telno)  */
                dial it;
        }
        else{
                hang up;
        }
}

Print statements showed the telno was being handed to the routine,
but the if said nothing was there.  Turns out, on my system, the
address of telno is NULL.  I needed to check the contents not the
address!
--

                        Bob Peirce, Pittsburgh, PA
                uucp: ...!{allegra, bellcore, cadre, idis}
                         !pitt!darth!investor!rbp
                                412-471-5320

                NOTE:  Mail must be < 30,000 bytes/message
(Mail) End of article 4847 (of 4956)--what next? [npq]

Article 4848 (108 more) in net.lang.c:
From: [e-mail] (Dave Brower)
Subject: C Idioms - reference work?
Message-ID: <[e-mail]>
Date: 16 Aug 85 08:00:52 GMT
Date-Received: 24 Aug 85 07:32:57 GMT
References: <[e-mail]> <[e-mail]>
Organization: Relational Technology, Alameda CA
Lines: 11

--MORE--(59%)I recall hearing a rumour a year or two ago about a hardcopy reference
to many common 'C' idioms.  It may have come out of some European
University.  Has anyone heard of such a beast, and know where I might
obtain a copy?

-dB

--
{amdahl|dual|sun|zehntel}\              |"If his brains ran down, how could
{ucbvax|decvax}!mtxinu---->!rtech!daveb |he talk?"
ihnp4!{phoenix|amdahl}___/              |"Happens to people all the time...."
(Mail) End of article 4848 (of 4956)--what next? [npq]

Article 4849 (107 more) in net.lang.c:
From: [e-mail] (Daniel R. Levy)
Subject: Re: how has C bitten you?  (Really, style)
Message-ID: <[e-mail]>
Date: 19 Aug 85 16:41:52 GMT
Date-Received: 24 Aug 85 09:45:17 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: net
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 30

--MORE--(33%)In article <[e-mail]>, [e-mail] (Roy Smith) writes:
>       Here's one that just got me:
>
>               if (sv > score);   <----- note extraneous semi-colon
>                       score = sv;
>
>       This was in a series of computations which gave various scores; the
>fragment above was repeated in various places to pick out the maximum.  Of
>course, the test is a no-op and the assignment was always done.  Naturally,
>this passes lint (even with the -h flag which uses "heuristic tests to
>attempt to intuit bugs") without any complaint.
>--
>Roy Smith <allegra!phri!roy>

Sounds like a question of style hiding function.  Why not stick to something
like

                if (sv > score) score = sv;

?

I can't think of anything much more straightforward than that.
--
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer, my pets, my plants, my boss, or the
| at&t computer systems division |  s.a. of any computer upon which I may hack.
|        skokie, illinois        |
|          "go for it"           |  Path: ..!ihnp4!ttrdc!levy
 --------------------------------     or: ..!ihnp4!iheds!ttbcad!levy
(Mail) End of article 4849 (of 4956)--what next? [npq]

Article 4851 (105 more) in net.lang.c:
From: [e-mail] (eric)
Subject: Re: VAX VMS C / UNIX C Compatibility --
Message-ID: <[e-mail]>
Date: 17 Aug 85 06:17:25 GMT
Date-Received: 26 Aug 85 02:56:32 GMT
References: <[e-mail]> <3400003@ndm20>
Organization: Brookhaven National Lab. Upton, N.Y.
Lines: 70

--MORE--(13%)> >Another thing I'm looking for under VMS is the ability to load both
> >C and FORTRAN object files into one executable. Does anyone know if
> >this works?
>
> It is supposed to but some while ago, there was a discussion on
> INFO-VAX saying that C in some way violated the VMS procedure calling
> standard. Thus there is one or more obscure case that fails. This
> is ironic in that the calling standard is highly touted by DEC. This
> discussion predated VMS4, so they may have fixed it.

I don't know if I would make too much of this.  The procedure calling
calling standard is only that and nothing more.  The fact that I can
violate the standard in C, is just a function of the fact that I can
do most anything in C.  I can violate the standard by doing certain
things in MACRO also, so this is just another example of "I can do
anything in C that I can do in MACRO".  There are rather simple
rules to follow if you are programming in C and are interfacing to
other languages to make a program comply with the procedure calling
standard.  Note that there is no problem if a program is entirely
written in C, so that this problem will not effect the porting
of existing C programs.

> There is also a general rule that happens to apply in this case, that
> I/O can only be done from routines in the same language as the main.
> This is because that is where most compilers on most machines put the
> calls to the I/O system initializers, and few languages share I/O
> systems. On some machines, you can't even do it if there are routines
> of another language between the main and the routine in question.

This may have been the case in an old version of VMS, but it certainly
isn't correct now.  I regularly mix FORTRAN and PASCAL I/O, and I just
verified that I can do C standard I/O mixed with PASCAL I/O.  In VMS
run-time systems, initialized data is linked in the run-time libraries
as initialized copy-on-reference data, and so no initialization needs
to be done at run time.  The biggest problem one is likely to run
into when mixing I/O to the terminal is that FORTRAN, PASCAL, and C
all have different ideas about carriage control, and each maintains
a separate picture of what carriage control characters are necessary.

> Terry Poot
> Nathan D. Maier Consulting Engineers
> [phone]
> Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp
> CSNET:  ndm20!tp@smu
> ARPA:   ndm20![e-mail]

In general, C programs that do I/O with standard I/O library
interfaces (getc, printf, etc...), use math library functions, and
that don't use things like stat and ioctl can be expected to work
unmodified on VMS systems.  Programs that use (read, write, open, creat)
will work in many cases, although they will have to be looked at
carefully.  In particular, the file formats may cause a problem.
Programs that rely on forking/vforking and pipes will probably
need major changes to run.  DEC supplies an implementation of
vfork and pipes, but it is so limited that I suspect it may not
be useful.  Still, if your program happens to fall within the
limitations, it may run, although with a severe performance problem.
There are many miscellaneous routines supplied for compatabilility with
UNIX, and if a program uses them, there is a large chance it will
work for both UNIX and VMS.  This compatability has expanded a lot
in the last release of the C compiler and I have not had a chance
to fully explore the new stuff.  It looks like there is even a
curses.

                                        Eric G. Stern
                                        Dept. of Physics SUNY StonyBrook
                                        [e-mail]
                                        [e-mail]
                                        [e-mail]
                                        ...!philabs!sbcs!bnl!stern
(Mail) End of article 4851 (of 4956)--what next? [npq]

Article 4852 (104 more) in net.lang.c:
From: [e-mail] (Isaac Dimitrovsky)
Subject: Bug in lint ?
Message-ID: <[e-mail]>
Date: 20 Aug 85 19:47:00 GMT
Date-Received: 26 Aug 85 03:48:25 GMT
Organization: New York University
Lines: 29

--MORE--(39%)[]

I've run into a possible bug in lint. It can be reproduced on my system
(VAX 4.2BSD) by running lint -ap on the program below. This produces:

try.c:
try.c(5): warning: long assignment may lose accuracy

The options a and p are supposed to check for assignments of longs to
ints and incompatibilities with the IBM and GCOS dialects of C,
respectively. Strangely enough, when I just run lint with the a option
or the p option alone, the program goes through with no messages.
Any explanations or ideas welcome.

main() {
        long a;
        int i;

        a=0; i=1;
        if ((a & (1L<<i)) != 0L)
                a++;
}

Isaac Dimitrovsky
allegra!cmcl2!csd2!dimitrov   (l in cmcl2 is letter l not number 1)
251 Mercer Street, New York NY 10012

... Hernandez steps in to face ... Orl ... HERchiiiser ... and it's a liiine
driive, deeeeep to the gap in left center ...   - Bob Murphy, Voice of the Mets
(Mail) End of article 4852 (of 4956)--what next? [npq]


Article 4854 (102 more) in net.lang.c:
From: [e-mail] (Jay Freeman)
Subject: Re: more about programming style
Message-ID: <[e-mail]>
Date: 21 Aug 85 20:39:56 GMT
Date-Received: 26 Aug 85 04:28:15 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>21 Aug 85 20:39:56 GMT
Reply-To: [e-mail] (Jay Freeman)
Organization: Schlumberger Palo Alto Research, CA
Lines: 17

--MORE--(48%)[libation to line-eater]

In article <[e-mail]> [e-mail] (Ray Butterworth) writes:

>Even simpler.  Replace "<=" with "!>", and ">=" with "!<".  This gives
>even more consistency since you can now have "!<", "!>", and "!=".

I suspect that Ray Butterworth may have had a :-) in mind when he wrote
these lines, but I kind of _like_ "!<" and "!>".  I guess I always think of
"<=" -- for example -- as two separate tests and have to combine both of
them mentally when I am figuring out what something does.  (Or maybe it's
brain-damage from writing too many lines of assembler.)  Anyway, those might
be a reasonable enhancement, and surely would be all but free in terms of
additional compiler complexity.


--
Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)
(Mail) End of article 4854 (of 4956)--what next? [npq]

Article 4855 (101 more) in net.lang.c:
From: [e-mail] (Robert Stroud)
Subject: Re: Exception Handling?  Impossible!
Message-ID: <[e-mail]>
Date: 19 Aug 85 16:40:50 GMT
Date-Received: 26 Aug 85 04:36:28 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Robert Stroud)
Organization: U. of Newcastle upon Tyne, U.K.
Lines: 25

--MORE--(46%)Rich Wagner ([e-mail]) posted some macros for exception handling
and asked for comments and suggestions.

I can recommend an article in Software Practice & Experience by Peter Lee
a few years ago (1983, pp 389-405) which describes a series of macros and
routines which add exception handling in the style of Ada or Clu to C.
Basically they work by hiding a stack of setjmp/longjmp contexts inside
a macro skeleton of

        BEGIN
           ...
        EXCEPT
           WHEN(exception1) ...
           WHEN(exception2) ...
           OTHERS ...
        END

I can post the code from the article if there is enough interest.

Robert Stroud,
Computing Laboratory,
University of Newcastle upon Tyne.

UUCP ...!ukc!cheviot!robert
ARPA [e-mail]
(Mail) End of article 4855 (of 4956)--what next? [npq]

Article 4856 (100 more) in net.lang.c:
From: [e-mail] (Bob Peirce)
Subject: Re: how has C bitten you? (and a sidetrack)
Message-ID: <[e-mail]>
Date: 19 Aug 85 00:00:19 GMT
Date-Received: 26 Aug 85 04:37:09 GMT
References: <[e-mail]> <2600011@ccvaxa> <[e-mail]>
Organization: Cookson, Peirce & Co., Pittsburgh, PA
Lines: 16

--MORE--(62%)>    What's worse, the optimiser has in this case hidden a program bug!!!
>
> Thus the moral:
>
>       "Don't just test your code once.  Test it again, this time
>        turn the optimiser OFF first".

and vice versa!
--

                        Bob Peirce, Pittsburgh, PA
                uucp: ...!{allegra, bellcore, cadre, idis}
                         !pitt!darth!investor!rbp
                                412-471-5320

                NOTE:  Mail must be < 30,000 bytes/message
(Mail) End of article 4856 (of 4956)--what next? [npq]

Article 4857 (99 more) in net.lang.c:
From: [e-mail] (Guy Harris)
Newsgroups: net.lang.c,net.unix
Subject: Re: Not checking printf's result causes another news bug
Message-ID: <[e-mail]>
Date: 20 Aug 85 06:12:30 GMT
Date-Received: 26 Aug 85 04:45:41 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <413@brl-Re: Not checking printf's re20 Aug 85 06:12:30 GMT
Followup-To: net.unix
Organization: Sun Microsystems, Inc.
Lines: 36

--MORE--(32%)> You could set up a (in unix lingo) a signal handler and if any I/O error
> occurred it would interrupt to that routine. Now this was on a per-write
> (actually, per I/O) basis but what I have in mind here is to do something
> like:
>
> #define printf eprintf
> #define fprintf efprintf
>
> then add to main() something like
>
>       signal(SIGIOT,myhandler) ;      /* choose a signal, SIGIOT seems good*/

No, SIGIOT is what "abort()" causes (except on 4.xBSD - in System V it uses
"kill" so that you can get SIGIOT even if you don't have an IOT
instruction).  In S3/S5/4.3BSD, you can use SIGUSR1; in older BSD releases,
#define SIGUSR1 as 30, and in V7 #define it as 16.  This signal (as the name
suggests) is reserved for user program use.

In System III and System V, though, there is a "software signal" mechanism -
see SSIGNAL(3C).  The claim is made there that "this facility is used by the
Standard C Library to enable users to indicate the disposition of error
signals", but this claims is false; nowhere in the C library is it used.  I
suspect it was intended for this purpose, but nobody bothered changing the
library to use it.  For those of you with non-S3 or S5 systems who have a
source license, you can drop it in.

> and something reasonable for myhandler() and finally:
>
> eprintf(fmt,a,b,c,d,e,f,g...) /* etc or maybe use varargs */
> {

Or, preferably, use "vprintf" and its siblings if you have them.  They come
with S3, and with S5R2, but *not* with S5R1.  They can be easily implemented
in any system with "_doprnt" (S5R2 has it and that's how it implements them).

        Guy Harris
(Mail) End of article 4857 (of 4956)--what next? [npq]

Article 4858 (98 more) in net.lang.c:
From: [e-mail] (Chris Shaw)
Subject: Re: how has C bitten you?  (Really, style)
Message-ID: <[e-mail]>
Date: 22 Aug 85 00:41:39 GMT
Date-Received: 26 Aug 85 05:10:44 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Chris Shaw)
Distribution: net
Organization: U of Waterloo, Ontario
Lines: 44

--MORE--(25%)In article <[e-mail]> [e-mail] (Daniel R. Levy) writes:
>In article <[e-mail]>, [e-mail] (Roy Smith) writes:
>>      Here's one that just got me:
>>              if (sv > score);   <----- note extraneous semi-colon
>>                      score = sv;
>
>Sounds like a question of style hiding function.  Why not stick to something
>like
>               if (sv > score) score = sv;
>?
>|       dan levy

...because

if(sv>score||this==that+the_other||fopen("crap","r"))save=the+whales+fur+christ++;

is the kind of statement where bugs really happen. Can you seriously spend less
than two seconds reading that to comprehend what's going on ? If you answered
yes, how about this (more important) question: Can you read a whole FILE of
this kind of crap and then be able to find a variable at will ?

I doubt it. I can think of more straightforward ways of producing code, some
of which include programming while awake, so that the errors like the
one in the original posting don't happen. Others include using a self-consistentstyle, which Mr Levy's is not. Compound if statements should look the same
as simple if statements.

Mr Levy's style of if statement has an equivalent in English called
"the run-on-sentence". What's silly about the whole thing is that a program
formatter can make this stuff QUITE readable, and will probably find the
bug that "bit" Mr Smith.

The most important element of a readable programming style is the use of white
space. I personally can't stand the K&R style because I get visually confused
when I read it. It's similar to an English paragraphing that doesn't use
indenting or spaces between paragraphs. In the C book itself, this isn't bad,
because the program fragments are small and the structures are simple.
In real programs, however, there are lots of programs which are unreadable
until passed through "indent" (on 4.2).


Chris Shaw    watmath!watmum!cdshaw  or  cdshaw@watmath
University of Waterloo
In doubt?  Eat hot high-speed death -- the experts' choice in gastric vileness !(Mail) End of article 4858 (of 4956)--what next? [npq]

Article 4859 (97 more) in net.lang.c:
From: [e-mail] (Chris Shaw)
Subject: Re: VAX VMS C / Rash attempt at porting Kermit
Message-ID: <[e-mail]>
Date: 22 Aug 85 01:08:01 GMT
Date-Received: 26 Aug 85 05:10:55 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Chris Shaw)
Organization: U of Waterloo, Ontario
Lines: 27

--MORE--(32%)In article <[e-mail]> [e-mail] (Norman Pritchett) writes:>cdshaw writes:
>> VMS is very record-ish, while stream i/o is the unix thing. Unfortunately,
>> port didn't work because we didn't really spend the effort required to do
>> the QIO's required to fake stream i/o on VMS.
>
>Huh?  On input Vax-11 C converts records with any attribute (implied
>carriage control, print carriage control, FORTRAN carriage control, null,
>and VFC) to stream format (read your "Programming in VAX-11 C" book
>AA-L370A-TE) so everything always looks like stream files on input.  On
>output, Vax-11 C creates stream files unless you go through the immense
>amount of effort to specify otherwise.
>--
>Norm Pritchett

Well, it WAS about 1.5 years ago, but if you'd read my posting, you may have
noticed the word "Kermit" pop up. You might even know that since Kermit
is a terminal-bashing program, it requires byte-by-byte I/O. GET IT? We didn't
want buffering. And we didn't really have a clear idea how to turn it off.
I vaguely recall that either setbuf wasn't available, or it didn't work,
or it didn't do what we wanted.

Anyway, that was ages ago, so don't bug me.

Chris Shaw    watmath!watmum!cdshaw  or  cdshaw@watmath
University of Waterloo
In doubt?  Eat hot high-speed death -- the experts' choice in gastric vileness !(Mail) End of article 4859 (of 4956)--what next? [npq]

Article 4860 (96 more) in net.lang.c:
From: [e-mail] (David Herron, NPR Lover)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 22 Aug 85 04:20:06 GMT
Date-Received: 26 Aug 85 05:12:25 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (David Herron, NPR Lover)
Organization: Univ. of KY Mathematical Sciences
Lines: 31

--MORE--(37%)In article <[e-mail]> [e-mail] (Robert Viduya) writes:
>In article <[e-mail]>, [e-mail] (d.s.klett) writes:
...
>>      typedef enum { False , True } Boolean;
...
>
>The problem with enums is that compiler allocate them as ints.  This
>means 1 wasted byte on a machine with a 16-bit int, 3 wasted bytes on
>a machine with a 32-bit int and so on and so forth.  All you really
>need is 1 byte (on most conventional machines).  I personally prefer:
>
>    #define    TRUE    1
>    #define    FALSE   0
>    typedef    char    bool;

Well, I personally prefer:

        #define TRUE (1==1)
        #define FALSE (1==0)
        typedef char bool;

Which is succint, to the point, and *machine*independant*!

'sides, constant expressions are calculated at compile time anyway.
--
--- David Herron
--- ARPA-> ukma![e-mail]
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
---        {ihnp4,decvax,ucbvax}!cbosgd!ukma!david

Hackin's in me blood.  My mother was known as Miss Hacker before she married!
(Mail) End of article 4860 (of 4956)--what next? [npq]

Article 4861 (95 more) in net.lang.c:
From: [e-mail]
Subject: Re: More Naughty Bits
Message-ID: <[e-mail]>
Date: 21 Aug 85 23:00:30 GMT
Date-Received: 26 Aug 85 05:18:19 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Dik T. Winter)
Distribution: net
Organization: CWI, Amsterdam
Lines: 12
Apparently-To: [e-mail]

--MORE--(56%)In article <[e-mail]> [e-mail] (Jeff Glass) writes:
>> (discussion about machines where 0.0 does not have same representation as 0)
>
>The CDC Cyber series represents floating-point zero with the (12-bit)
>exponent zero.  It doesn't matter whether the (48-bit) mantissa is zero
>or not.

Not quite, for floating-point multiplication: yes; for floating-point
addition: no.  (There are numbers such that 2.0*x = 0.0, but x+x /= 0.0)
--
dik t. winter, cwi, amsterdam, nederland
UUCP: {seismo|decvax|philabs}!mcvax!dik
(Mail) End of article 4861 (of 4956)--what next? [npq]

Article 4862 (94 more) in net.lang.c:
From: [e-mail] (Henry Spencer)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 19 Aug 85 21:48:35 GMT
Date-Received: 26 Aug 85 05:20:08 GMT
References: <[e-mail]>, <[e-mail]>
Organization: U of Toronto Zoology
Lines: 11

--MORE--(59%)>       typedef int     bool;
>       #define false   0
>       #define true    1

It's interesting to note that Kernighan&Plauger use "yes" and "no" rather
than "true" and "false", and my own reaction is that the code often reads
better that way.  Now that's something to *really* start a raging debate
about... :-)
--
                                Henry Spencer @ U of Toronto Zoology
                                {allegra,ihnp4,linus,decvax}!utzoo!henry
(Mail) End of article 4862 (of 4956)--what next? [npq]

Article 4863 (93 more) in net.lang.c:
From: [e-mail]
Subject: How do I declare...
Message-ID: <[e-mail]>
Date: 21 Aug 85 18:18:56 GMT
Date-Received: 26 Aug 85 06:09:35 GMT
Organization: Personal Scientific Corporation, Woodinville, WA, USA, Earth...
Lines: 32

--MORE--(30%)Either I'm missing the perfectly obvious or I've found something
that's impossible to declare in C, even though it makes sense.  I'm
trying to implement a simple finite state machine with states
represented by C functions.  Each state function would accept some
input value as an argument and return a pointer to the function
implementing the next state, something like this:

STATE_FUNC (*state)(),   /* the current state         */
           *state_1(),   /* a function for each state */
            ... ,
           *state_n();

   for (;;) {
      state = (*state)(get_input());
   }

But how is STATE_FUNC typedef'ed?  It's a pointer to a function which
returns a pointer to a function which returns a pointer...  Any
suggestions?

Obviously, there are other ways to implement a finite state machine,
and I have already chosen one.  Yet this one is conceptually clean, and
it seems that there must be some way to do it; plus, this could turn
out to be a more interesting discussion than i++ vs. i = i + 1...

--
Bill Roman      {ihnp4,decvax,allegra,...}!uw-beaver!tikal!persci!roman

Summation, Inc, (formerly Personal Scientific Corporation)
18702 142nd Ave NE
Woodinville, WA 98072
[phone]
(Mail) End of article 4863 (of 4956)--what next? [npq]

Article 4864 (92 more) in net.lang.c:
From: [e-mail] (ben)
Subject: Xinu -- any experience ??
Message-ID: <[e-mail]>
Date: 20 Aug 85 20:18:57 GMT
Date-Received: 26 Aug 85 06:17:23 GMT
Organization: CERN, Geneva/Switzerland
Lines: 8

--MORE--(67%)
  Does anyone out there have experience of making PRACTICAL
applications using Douglas Comer's Xinu system?  We are
interested particularly in any real-time applications for
68000's.

   Ben M. Segal,  CERN-DD,  1211 Geneva 23,  Switzerland
                  (ben@cernvax via mcvax)
(Mail) End of article 4864 (of 4956)--what next? [npq]

Article 4865 (91 more) in net.lang.c:
From: [e-mail] (Doug Moen)
Subject: Re: How do I declare... (recursive typedefs)
Message-ID: <[e-mail]>
Date: 24 Aug 85 19:42:50 GMT
Date-Received: 26 Aug 85 06:42:10 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Doug Moen)
Organization: U of Waterloo, Ontario
Lines: 38
Summary: You can't do recursive typedefs

--MORE--(33%)In article <[e-mail]> [e-mail] writes:
>Either I'm missing the perfectly obvious or I've found something
>that's impossible to declare in C, even though it makes sense.  I'm
>trying to implement a simple finite state machine with states
>represented by C functions.  Each state function would accept some
>input value as an argument and return a pointer to the function
>implementing the next state, something like this:
>
>STATE_FUNC (*state)(),   /* the current state         */
>           *state_1(),   /* a function for each state */
>            ... ,
>           *state_n();
>
>   for (;;) {
>      state = (*state)(get_input());
>   }
>
>But how is STATE_FUNC typedef'ed?  It's a pointer to a function which
>returns a pointer to a function which returns a pointer...  Any
>suggestions?

You aren't missing the perfectly obvious.
Yes, it is impossible to declare in C, even though it makes sense.

What you want is a recursive typedef:
        typedef STATE_FUNC (*STATE_FUNC)();
except that this isn't allowed.

What you will have to do instead is a kludge:
        typedef char* (*STATE_FUNC)();

        for (;;) {
                /* Note the cast: */
                state = (STATE_FUNC) (*state)(get_input());
        }
--
Doug Moen (watmath!watcgl!kdmoen)
University of Waterloo Computer Graphics Lab
(Mail) End of article 4865 (of 4956)--what next? [npq]

Article 4866 (90 more) in net.lang.c:
From: [e-mail] (Norman Pritchett)
Subject: Re: Re: VAX VMS C / Rash attempt at porting Kermit
Message-ID: <[e-mail]>
Date: 24 Aug 85 21:07:38 GMT
Date-Received: 26 Aug 85 06:50:59 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Ohio State Univ., CIS Dept., Cols, Oh.
Lines: 24

--MORE--(40%)> Well, it WAS about 1.5 years ago, but if you'd read my posting, you may have
> noticed the word "Kermit" pop up. You might even know that since Kermit
> is a terminal-bashing program,it requires byte-by-byte I/O. GET IT? We didn't
> want buffering. And we didn't really have a clear idea how to turn it off.
> I vaguely recall that either setbuf wasn't available, or it didn't work,
> or it didn't do what we wanted.
>
> Anyway, that was ages ago, so don't bug me.
>
> Chris Shaw    watmath!watmum!cdshaw  or  cdshaw@watmath
> University of Waterloo
> In doubt?  Eat hot high-speed death -- the experts' choice in gastric vileness !

Duh, oops.  Sorry,  every once in a while the connection doesn't quite make
it.


--
-----------------------------------
Norm Pritchett
UUCP:   cbosgd!osu-eddie!pritch         P.O. Box 3393
CSNET:  pritch@ohio-state               Columbus OH 43210
BITNET: TS1703 at OHSTVMA
Bellnet: [phone]
(Mail) End of article 4866 (of 4956)--what next? [npq]

Article 4867 (89 more) in net.lang.c:
From: [e-mail] (Barry Shein)
Newsgroups: net.lang.c,net.unix-wizards
Subject: Re: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 24 Aug 85 06:58:57 GMT
Date-Received: 26 Aug 85 06:51:44 GMT
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Organization: Boston Univ Comp. Sci.
Lines: 16

--MORE--(56%)Not really a bite, but I remember when I was first learning C
I was quite bewildered by the fact that you couldn't really
declare your own 'argv', that is, you couldn't declare an
array of pointers to fixed length buffers except perhaps by:

char *myargv[] = {
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
        "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",

        etc

I mean, argv seemed kinda holy to me, disturbing.

        -Barry Shein, Boston University

P.S. I know argv is var length, but that would be even harder to declare!
(Mail) End of article 4867 (of 4956)--what next? [npq]

Article 4868 (88 more) in net.lang.c:
From: [e-mail] (Ed Schwalenberg)
Subject: Good C compilers for 68000
Message-ID: <[e-mail]>
Date: 21 Aug 85 21:11:41 GMT
Date-Received: 26 Aug 85 06:59:41 GMT
Sender: [e-mail]
Lines: 16

--MORE--(34%)We've been using Microsoft's Xenix on Microbar hardware to develop and
run large C applications.  We have reached the point where our programs
are too large and too complex for the compiler provided with Xenix.
Things like limits on the number of #defines, limits on the nesting of
structures, and the like are giving us fits.  And the code produced by
this compiler (a descendent of the MIT port of the portable compiler)
is awful.

Are there better compilers out there?  Where do I get them?  Microsoft
refuses to talk with us since Microbar as OEM is supposed to handle
such things.  Microbar is too busy trying to stay afloat.  Tartan only
has products for the Vax.  We tried a Whitesmiths product several years
ago which was even worse, as was a compiler from a company called Alcyon.
I've heard rumors about the "Green Hills" compiler, but have been unable
to find out how to get in touch with them.  Any help would be appreciated.
Please reply to me directly, as I don't subscribe to these lists.
(Mail) End of article 4868 (of 4956)--what next? [npq]

Article 4871 (85 more) in net.lang.c:
From: [e-mail]
Subject: Cryptic Code
Message-ID: <[e-mail]>
Date: 21 Aug 85 23:26:55 GMT
Date-Received: 26 Aug 85 07:01:21 GMT
Sender: [e-mail]
Lines: 17

--MORE--(55%)/*
> Does anyone out there support the author by saying that Version 3 of
> 'strcpy' is better than Version 2?

Definitely. You are thinking in terms of another language instead of
thinking in C. This is like trying to speak french while translating
to/from english as you go, n'est ce pas?

> Bob Crane
> !tektronix!tektools!bobc
> [phone]

or you can always try:  stalag13!hogan  :-)

        jim             cottrell@nbs
*/
------
(Mail) End of article 4871 (of 4956)--what next? [npq]

Article 4873 (83 more) in net.lang.c:
From: [e-mail]
Subject: C bites Dog!
Message-ID: <[e-mail]>
Date: 22 Aug 85 01:10:37 GMT
Date-Received: 26 Aug 85 07:01:54 GMT
Sender: [e-mail]
Lines: 53

--MORE--(20%)/*
> > > ???:
> > >           if (sv > score);   <----- note extraneous semi-colon
> > >                   score = sv;
> > Doug Gwyn:
> > This sort of thing makes me think that a few extra keywords
> > are called for programming languages like this.  E.g.
> >     if <bool_expr> then <stmt> fi
> >     while <bool_expr> do <stmt> od
> > Something to keep in mind when you design an Algol-like language.
>
> ICK ICK ICK! I hate languages that do that. Ever considered using "cb" as a
> debugging tool? I have an MS-DOS version if anyone wants it...
> --
>       Peter da Silva (the mad Australian werewolf)
>               UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
>               MCI: PDASILVA; CIS: 70216,1076

Dear Peter,

        Welcome to the `Let's Disagree with Doug' club! Unfortunately,
I am forced to agree with him here. CB (& INDENT) is A Good Thing,
but since I am such a wonderful coder (:-) I rarely use them. What they
really are useful for is importing code written by cretins. Also, I
probably disagree slightly with the output of those formatters. What
would you do, compare the output of `cb' with the original? Takes
lots of time & can be visually overlooked.

        Anyway, to get back to the point, you come to realize that in

                if <exp> then <stmt> else <stmt> fi

the parens around <exp> are unneccesary. And the `fi' makes sure that
all the elses nest with the correct `if'. The Bourne shell has the
following definitions, (which many peole dislike, but I think they're OK)

        #define IF      if(
        #define THEN    ){
        #define ELSE    }else{
        #define FI      }

The point is, you need at least 4 tokens (or a `one-statement' model)
to delimit the three parts of an `if' from each other and the outside.
C uses four (not counting semicolons)in the short form
(if (e) s1; else s2;) and eight in the long form
(if (e) { s1; } else { s2; }). And let's get rid of those semicolons
too! A newline should imply one. Two statements on a line would need
an explicit one. An escaped newline would continue to the next line.
Yeah, I know, write my own language!

        jim             cottrell@nbs
*/
------
(Mail) End of article 4873 (of 4956)--what next? [npq]

Article 4875 (81 more) in net.lang.c:
From: [e-mail] (Mike Shannon)
Subject: C bites / programming style
Message-ID: <[e-mail]>
Date: 23 Aug 85 17:37:13 GMT
Date-Received: 26 Aug 85 07:39:49 GMT
Distribution: net
Organization: 3Com Corp; Mountain View, CA
Lines: 14

--MORE--(51%)With regard to:
        if(condition);          /* the bug is the seimcolon on this line */
                statement;      /* this statement was intended to be
                                 * executed iff the condition was true
                                 */
--------------------
        I avoid getting bitten in this way by ALWAYS using {}'s after
if, while, etc.  Even when I have a null statement as the body of an
while or for, I do it this way:
        for(i = 0; i < MAX; i++) {
        }
Always using braces with if/else also removes ambiguity concerning
"which if an else belongs to."
                                -Michael Shannon (hplabs!oliveb!3comvax!mikes)
(Mail) End of article 4875 (of 4956)--what next? [npq]

Article 4876 (80 more) in net.lang.c:
From: [e-mail] (David Eppstein)
Subject: Re: How do I declare...
Message-ID: <[e-mail]>
Date: 25 Aug 85 00:08:06 GMT
Date-Received: 26 Aug 85 22:58:10 GMT
References: <[e-mail]>
Reply-To: [e-mail] (David Eppstein)
Organization: Columbia University
Lines: 9

--MORE--(56%)In article <[e-mail]> [e-mail] writes:
> Either I'm missing the perfectly obvious or I've found something
> that's impossible to declare in C, even though it makes sense.  I'm
> trying to implement a simple finite state machine with states
> represented by C functions.  Each state function would accept some
> input value as an argument and return a pointer to the function
> implementing the next state...

It works if you imbed them in a struct.  Kind of ugly though.
(Mail) End of article 4876 (of 4956)--what next? [npq]

Article 4877 (79 more) in net.lang.c:
From: [e-mail] (Richard L. Klappal)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 25 Aug 85 08:38:34 GMT
Date-Received: 26 Aug 85 22:59:32 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Richard L. Klappal)
Organization: chinet, Public Access UN*X, Chicago
Lines: 52
Summary:

--MORE--(26%)In article <[e-mail]> [e-mail] (Robert Viduya) writes:
>In article <[e-mail]>, [e-mail] (David Herron, NPR Lover) writes:
>> In article <[e-mail]> [e-mail] (Robert Viduya) writes:
>> >
>> > ... I personally prefer:
>> >
>> >    #define TRUE    1
>> >    #define FALSE   0
>> >    typedef char    bool;
>>
>> Well, I personally prefer:
>>
>>      #define TRUE (1==1)
>>      #define FALSE (1==0)
>>      typedef char bool;
>>
>> Which is succint, to the point, and *machine*independant*!
>>
>
>Oh?  On what machine is (1==1) equal to 0, or (1==0) not equal to 0?  In
>section 7.6 (Relational operators, Appendix A - C Reference Manual from
>K&R's The C Programming Language), it explicitly states that the logical
>operators all yield 0 if the relation is false and 1 if the relation is
>true.  Nothing is mentioned about possible variations due to implementation
>machine differences.
>
>                               robert
>--
>Robert Viduya                                                  01111000
Maybe not 'machine independent' in C, but the logic will
be 'language independent' (using the appropriate equality operator).

I've had to debug an awful lot of assembly language where
a cpu 'Z' flag (zero-flag) was used as TRUE.  About like strcmp
returns 0 if two strings are the same so that you cannot extend
the concept

        if (string1==string2) {...}

that works in F77, PL/I, BASIC, etc.



Richard Klappal

UUCP:           ..!ihnp4!chinet!uklpl!rlk  | "Money is truthful.  If a man
MCIMail:        rklappal                   | speaks of his honor, make him
Compuserve:     74106,1021                 | pay cash."
USPS:           1 S 299 Danby Street       |
                Villa Park IL 60181        |    Lazarus Long
TEL:            [phone]             |        (aka R. Heinlein)
-------------------------------------------------------------------------
(Mail) End of article 4877 (of 4956)--what next? [npq]

Article 4878 (78 more) in net.lang.c:
From: [e-mail] (Andrew Koenig)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 25 Aug 85 15:38:12 GMT
Date-Received: 26 Aug 85 23:02:42 GMT
References: <[e-mail]>
Organization: Bell Labs, Murray Hill
Lines: 13

--MORE--(46%)> I have always thought that to be a machine dependancy (the value of true and
> false).  Maybe I'm wrong.  But, different machines DO have different ideas
> of which is true and false (at the assembler level).  And it is simply
> a convention.

You are wrong: the value of true and false in C is defined as part of
the language:

When I write    if(exp) foo(); else bar();   foo is called if exp is
nonzero and bar is called if exp is zero.

The result of relational operators, &&, ||, and ! is always 1 or 0
(not some random machine-dependent value or zero).
(Mail) End of article 4878 (of 4956)--what next? [npq]

Article 4879 (77 more) in net.lang.c:
From: [e-mail] (Arnold Robbins)
Subject: Re: How do I declare...
Message-ID: <[e-mail]>
Date: 25 Aug 85 17:38:54 GMT
Date-Received: 27 Aug 85 00:42:07 GMT
References: <[e-mail]> <[e-mail]>
Organization: Pr1mebusters!
Lines: 23

--MORE--(39%)

Article 4880 (76 more) in net.lang.c:
From: [e-mail] (Arthur David Olson)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 24 Aug 85 16:21:43 GMT
Date-Received: 27 Aug 85 03:16:26 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: NIH-LEC, Bethesda, MD
Lines: 29
Summary: The good news and the other news about (1==1)

--MORE--(44%)> > > . . .I personally prefer:
> > >
> > >    #define        TRUE    1
> > >    #define        FALSE   0
> > > . . .
> > . . .I personally prefer:
> >
> >     #define TRUE (1==1)
> >     #define FALSE (1==0)
> > . . .
> Oh?  On what machine is (1==1) equal to 0, or (1==0) not equal to 0? . . .

Yes, the good book (K&R) says that (1==1) is always 1.
The advantage of the second approach above is that it obviates the need to
remember this fact.  The disadvantage of the second approach above is that it
gives "lint" fits ("constant in conditional context").

As for what *I* prefer:

        #ifndef TRUE
        #define TRUE    (1)
        #define FALSE   (0)
        #endif

where the parenthesized definitions match those in "curses.h" to ensure that
if a reference to "curses.h" appears after the above lines I won't get a
"macro redefined to a different value" diagnostic from the C preprocessor.

                                --ado
(Mail) End of article 4880 (of 4956)--what next? [npq]

Article 4881 (75 more) in net.lang.c:
From: [e-mail] (Doug Landauer)
Subject: Re: Cryptic C (Actually typedef ? boolean;)
Message-ID: <[e-mail]>
Date: 20 Aug 85 19:08:04 GMT
Date-Received: 27 Aug 85 08:32:23 GMT
References: <[e-mail]> <[e-mail]>
Organization: Digital Research, Monterey, CA
Lines: 17

--MORE--(56%)Doug Gwyn says:
> I am pretty conservative when it comes to defining one's own
> language extensions, this one seems like a winner:
>
>       typedef int     bool;
>       #define false   0
>       #define true    1

My favorite way to do this one is
        typedef enum { false, true } boolean ;

It provides a little more type checking than your typedef.
--
                        -- Doug Landauer --
        ...[ ihnp4 | mot | ucscc | amdahl ] !drivax!landauer
                -- "I survived the DRI layoffs." --
                        -- "(So far!)" --
(Mail) End of article 4881 (of 4956)--what next? [npq]

Article 4882 (74 more) in net.lang.c:
From: [e-mail] (Alexis Dimitriadis)
Subject: Re: C bites Dog!
Message-ID: <[e-mail]>
Date: 25 Aug 85 05:25:22 GMT
Date-Received: 27 Aug 85 10:34:26 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Alexis Dimitriadis)
Organization: Reed College, Portland, Oregon
Lines: 70
Summary:

--MORE--(16%)> > > >                 if (sv > score);   <----- note extraneous semi-colon
> > > >                         score = sv;
> > ICK ICK ICK! I hate languages that do that. Ever considered using "cb" as a
> > debugging tool? I have an MS-DOS version if anyone wants it...
> [...]  What
> would you do, compare the output of `cb' with the original? Takes
> lots of time & can be visually overlooked.

  Here is an idea I've had on the back burner for while: How about a
program that checks the formatting of the source code for consistency?
  - Take a C beautifier.
  - Modify the lexical analyzer so it passes the amount of indentation
    preceding the line each input statement is on.
  - Now for each statement, check the _relative_ indentation.  A normal
    statement should be indented exactly as far as the previous statement;
    the subordinate part of an "if" or a loop should be further indented,
    or be on the same line; lines that contain continuation of an expression
    can start anywhere, and do not affect the expected indent; etc.
  - If the input disagrees, give a diagnostic.

  This should catch things like
    if (tv.set == junk);
        turn(off);
or even
    while (cat == away)
        mice(dance);
        cheese--;
since the "while" should be aligned with the "cheese".  Of course,
it would be powerless with
    if (procter & gamble); chips++;
unless you put in a rule about multiple equal-level statements on the
same line, which would create problems with macro expansion, etc.

  Now I haven't started work on this yet, (first I finish my thesis),
but it seems it could be made to work consistently, and without a lot
of false alarms.  However, a friend who may know better disagrees.
Are there really impossible obstacles to the task?  I know the lexical
analyzer would have to keep track of the offset, and probably line
number, of every token, but that's no big deal.

  Could it cope with the thousands of indenting styles?  I think the
test is general anough to cope with anything.  Since there are so many
places braces can be, they could be just ingored.

  Is it a pipe dream? Has it been done before?  (If it has, it must be
a well kept secret!).  What should I watch out for? Whose code would
it gag on?  If you have the answers to any of this, (or even some good
questions), I would appreciate hearing from you.

  Finally, I apologize for the length of this, and please! none of the
above condones of condemns any particular style of indenting, the
subject has been trashed to death anyway.  I have kept the results of
the indenting style survey, I will mail them to anyone interested.

Thanks for your attention,
Alexis Dimitriadis

  PS. I have lost the name of the person who conducted the survey.  If
you still have the "other style" answers, could you send me a list?
--
_______________________________________________
  As soon as I get a full time job, the opinions expressed above
will attach themselves to my employer, who will never be rid of
them again.

             alexis @ reed

                 ...teneron! \
...seismo!ihnp4! - tektronix! - reed.UUCP
     ...decvax! /
(Mail) End of article 4882 (of 4956)--what next? [npq]

Article 4883 (73 more) in net.lang.c:
From: [e-mail] (David Herron, NPR Lover)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 25 Aug 85 06:37:23 GMT
Date-Received: 27 Aug 85 11:06:59 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (David Herron, NPR Lover)
Organization: Univ. of KY Mathematical Sciences
Lines: 47

--MORE--(22%)In article <[e-mail]> [e-mail] (Robert Viduya) writes:
>In article <[e-mail]>, [e-mail] (David Herron, NPR Lover) writes:
>> Well, I personally prefer:
>>
>>      #define TRUE (1==1)
>>      #define FALSE (1==0)
>>      typedef char bool;
>>
>> Which is succint, to the point, and *machine*independant*!
>>
>
>Oh?  On what machine is (1==1) equal to 0, or (1==0) not equal to 0?  In
>section 7.6 (Relational operators, Appendix A - C Reference Manual from
>K&R's The C Programming Language), it explicitly states that the logical
>operators all yield 0 if the relation is false and 1 if the relation is
>true.  Nothing is mentioned about possible variations due to implementation
>machine differences.

I don't particularly care if it's defined to be machine independant already.

I have always thought that to be a machine dependancy (the value of true and
false).  Maybe I'm wrong.  But, different machines DO have different ideas
of which is true and false (at the assembler level).  And it is simply
a convention.

Still though, #define TRUE (1==1) is very obvious, to the point, correct,
proper, and all sorts of things.  And it doesn't require one to know
that detail about C that the convention is ~0 == TRUE and 0 == FALSE.

When I'm writing C I think of it has a *high*level*language*.  Not as
simply one step away from assembler.  The difference between C and other
*high*level*languages* is that it gives you precise control over an
idealized machine.  This is what confuses most people about C, because
it can *feel* like assembler.  Especially when they've learned it on a
PDP-11 and think like an assembly programmer.

But C gives you all these operators which allow you to define things
machine independantly rather than hardcoding values.  Obviously I mean
casts and the sizeof operator.  Also arithmetic to pointers.  So why not
TRUE and FALSE?
--
--- David Herron
--- ARPA-> ukma![e-mail]
--- UUCP-> {ucbvax,unmvax,boulder,oddjob}!anlams!ukma!david
---        {ihnp4,decvax,ucbvax}!cbosgd!ukma!david

Hackin's in me blood.  My mother was known as Miss Hacker before she married!
(Mail) End of article 4883 (of 4956)--what next? [npq]

Article 4884 (72 more) in net.lang.c:
From: [e-mail] (Guy Harris)
Subject: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 24 Aug 85 22:43:37 GMT
Date-Received: 28 Aug 85 03:02:59 GMT
References: <[e-mail]> <[e-mail]>
Organization: Sun Microsystems, Inc.
Lines: 62

--MORE--(20%)>   [ ... ]
> >     if(telno){              /*  should be if(*telno)  */
>   [ ... ]
>
> > Print statements showed the telno was being handed to the routine,
> > but the if said nothing was there.  Turns out, on my system, the
> > address of telno is NULL.  I needed to check the contents not the
> > address!
>
> Gee....and I thought a zero pointer was guaranteed not to point to
> anything valid (K&R says this).

All valid implementations of C guarantee this.  Obviously, the
implementation of C that this was done on is not valid.  He should complain
to the vendor.  (Yes, there have been such implementations; one well-known
chip maker's first UNIX release didn't put the necessary shim at data
location 0 on a separate I&D space program.  They fixed it shortly
afterwards.)

> Or is NULL not a zero?!  No, you are comparing to 0 not NULL.

If you compare a pointer against 0, the actual code compiled compares it
against a null pointer.  NULL *is* 0, if you're talking from the standpoint
of "what does the '#define' in <stdio.h> and other places say":

        /*      @(#)stdio.h 1.2 85/01/21 SMI; from UCB 1.4 06/30/83     */

        ...

        #define NULL    0

(and you'll find the same thing in V7, 4.2, 4.3, S3, S5, ...).  In any
context where it is known to the compiler that something is supposed to be a
pointer to a specific data type, any zero that appears there is treated as a
null pointer of the type "pointer to that data type" (obviously, not a null
pointer to an object of that data type, since a null pointer can't point to
anything).  These contexts include comparisons and assignments, so the two
assignments in

        register struct frobozz *p;

        p = 0;
        p = (struct frobozz *)0;

are equivalent and the two comparisons in

        if (p == 0)
                foo();
        if (p == (struct frobozz *)0)
                foo();

are equivalent.  Procedure calls, however, are not such a context, so the
two procedure calls in

        bar(0);
        bar((struct frobozz *)0);

are very definitely *not* equivalent.  In ANSI Standard C, there is a syntax
to specify that "bar" takes an argument of type "struct frobozz *"; if you
declared "bar" in such a manner, the two procedure calls would be equivalent.

        Guy Harris
(Mail) End of article 4884 (of 4956)--what next? [npq]


Article 4886 (70 more) in net.lang.c:
From: [e-mail] (Doug Gwyn <gwyn>)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 22 Aug 85 21:57:19 GMT
Date-Received: 28 Aug 85 03:03:49 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Ballistic Research Lab
Lines: 3

--MORE--(77%)The reason I didn't use char or enum for boolean data definition
is that that is not how C actually works.  Int is a more accurate
representation of the current state of affairs.
(Mail) End of article 4886 (of 4956)--what next? [npq]

Article 4887 (69 more) in net.lang.c:
From: [e-mail] (Doug Gwyn <gwyn>)
Subject: Re: Cryptic C
Message-ID: <[e-mail]>
Date: 22 Aug 85 21:59:24 GMT
Date-Received: 28 Aug 85 03:03:56 GMT
References: <[e-mail]>, <[e-mail]> <[e-mail]>
Organization: Ballistic Research Lab
Lines: 5

--MORE--(72%)> It's interesting to note that Kernighan&Plauger use "yes" and "no" rather
> than "true" and "false", ...

Yes, but the conventional use in symbolic logic is true/false.
One is not always asking a natural yes/no question of a predicate.
(Mail) End of article 4887 (of 4956)--what next? [npq]

Article 4888 (68 more) in net.lang.c:
From: [e-mail] (Mark Rosenthal)
Subject: Suggestion to enhance code readability
Message-ID: <[e-mail]>
Date: 22 Aug 85 23:21:32 GMT
Date-Received: 28 Aug 85 03:05:00 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: net
Organization: Adaptive Optics Assoc., Cambridge, Mass. USA
Lines: 30

--MORE--(33%)Although our site has been receiving articles for the past few months,
articles posted to the net have not been getting distributed until recently.
The following is a reposting of an article I sent out quite some time ago.
I believe it never made it to the net at large.  Apologies if you have seen
this before.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Alexis Dimitriadis (alexis @ reed) writes:

>   Expressions like "while (var++) ;" introduce problems that take
> (bitter) experience before they can be handily detected, even if the
> reader is familiar with the semantics of the expression.  That is the
> real reason it takes a seasoned C programmer to debug seasoned C code.

Since every simple C statement ends with a ";", it is easy to misread
the ";" in the above as a terminator for the while statement, rather
than a terminator for a null statement controlled by the while.  Placing
the ";" on the same line as the while makes this misinterpretation very
likely.  That is why I came up with the following (equivalent) construction,
which I have been using for several years.  I believe it enhances readability.
But then, I have weird tastes.

        while (var++)
            { }


--

        Mark of the Valley of Roses
        ...!{decvax,linus,ima,ihnp4}!bbncca!aoa!mbr
(Mail) End of article 4888 (of 4956)--what next? [npq]

Article 4889 (67 more) in net.lang.c:
From: [e-mail] (Paul Van de Graaf)
Subject: Re: C bites Dog!
Message-ID: <[e-mail]>
Date: 24 Aug 85 10:33:25 GMT
Date-Received: 28 Aug 85 03:07:51 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Paul Van de Graaf{|stu)
Organization: U.C. San Diego, Academic Computer Center
Lines: 28

--MORE--(27%)In article <[e-mail]> [e-mail] writes:
>The point is, you need at least 4 tokens (or a `one-statement' model)
>to delimit the three parts of an `if' from each other and the outside.
>C uses four (not counting semicolons)in the short form
>(if (e) s1; else s2;) and eight in the long form
>(if (e) { s1; } else { s2; }). And let's get rid of those semicolons
>too! A newline should imply one. Two statements on a line would need
>an explicit one. An escaped newline would continue to the next line.
>Yeah, I know, write my own language!
>
>       jim             cottrell@nbs

        Couldn't agree with Jim more!  Especially on the no semi-colon point.
I use Action! (a C/Pascal/Basic derivative) on my Atari, and it has this
feature.  If Action! had all of C's operators, had more reasonable data types
(better struct/unions etc.), AND supported recursion, I'd never look back.
Action also has the if <> then <> fi style bracketing which I suppose was
inspired by the Bourne shell.  I personally don't like the case .. esac stuff
in the Bourne shell, but I can't understand why C programmers are so concerned
about typing 2 to 5 letter keywords instead of (, ), {, and }.  I don't type
special characters very well, and I think it's because of having to hit that
<shift> key.  The QWERTY system is at its best when typing alphas; anything
else slows you down, especially when you have to look for the "weird" keys
that various brain-damaged manufacturers put in all kinds of crazy positions.
I'm ready for something beyond C, and I don't mean C++ or Ada.  If no one
obliges all just have to do as Jim says and write my own.

Paul van de Graaf       sdcsvax!sdcc3!ee161bep          U. C. San Diego
(Mail) End of article 4889 (of 4956)--what next? [npq]


Article 4893 (63 more) in net.lang.c:
From: [e-mail] (Roy Smith)
Subject: Re: C bites / programming style [if (cond); statement;]
Message-ID: <[e-mail]>
Date: 25 Aug 85 19:11:01 GMT
Date-Received: 28 Aug 85 04:16:51 GMT
References: <[e-mail]>
Distribution: net
Organization: Public Health Research Inst. (NY, NY)
Lines: 62

--MORE--(16%)>       I avoid getting bitten in this way by ALWAYS using {}'s after
> if, while, etc.  Even when I have a null statement as the body [...]
> -Michael Shannon (hplabs!oliveb!3comvax!mikes)

        Since I was the original poster of this particular bite, let me
add a few random comments.  First off, I'm really kind of amazed how much
discussion this is getting.  I wish people would pay this much attention
when I do things correctly!

        Oddly enough, part of the bite was from emacs.  Since the code in
question was repeated several times with small changes, I wrote it once and
used a macro to duplicate and modify it each time.  My real goof was in
defining the emacs macro.  I somehow dragged the extra semi-colon along
causing an error I probably wouldn't have made if I wrote each fragment by
hand.  Shows me to try and be clever.

        I put null loop-bodies on a separate line like in the following
example.  You all know how I write null if-bodies. :-)

                while (eatup() != '\n')
                        ;

        If the body of the [whatever] is a single simple statement, I leave
out the braces and do something like the following (I'm using "simple" in
the generic sense, not strictly as defined by the C grammer):

        if (foo >= bar)         |       while (*foo++ == bar)
                sum += foo;     |               printf ("still a bar\n");
        else                    |
                toosmall++;     |

        If the body is more complicated than an assignment or function
call, I put it in braces, even though they really aren't needed, thus:

        while ((foo = getfoo()) != EOF) |
        {                               |       for (x=0; x <= 10; x++)
                if (foo >= bar)         |       {
                        sum += foo;     |               for (y=0; y <= 10; y++)
                else                    |                       sumxy += x * y;
                        toosmall++;     |       }
        }                               |

        The entire "if-else" or "for" construct is a single statement, but
intuitively I think about lines and statements being the same (probably a
holdover from my Fortran days).  If I write a multi-line statement, I put
braces around it to make that clear (to myself, if nobody else).  Actually,
in the "for" example above, I would probably drop the braces.  If, however,
the inner loop needed braces, the outer one would be sure to get them too.

        A few people have suggested I run my source through a code grinder
like "cb".  If the output of cb is different from its input, it's a hint I
goofed somewhere.  Something like "cb < foo.c | diff foo.c -" would do the
job nicely.  While this is a good idea, I don't see why this isn't built
into "lint".

        OK, now can we please start working on somebody else's boo-boos?
It's embarrassing to see my dirty laundry come back at me 6 times a day,
even if it is somewhat amusing.
--
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016
(Mail) End of article 4893 (of 4956)--what next? [npq]

Article 4894 (62 more) in net.lang.c:
From: [e-mail] (Jay Fields)
Newsgroups: net.lang.c,net.micro.mac
Subject: help with sizeof() in HIPPO-C
Message-ID: <[e-mail]>
Date: 23 Aug 85 04:25:54 GMT
Date-Received: 28 Aug 85 05:02:27 GMT
Distribution: net
Organization: Islenet Inc.,  Honolulu
Lines: 9

--MORE--(66%)Just discovered that there does not seem to be a sizeof() function
in Hippo C level I or II.  This would sure be useful for passing
the number of elements to an array sorting function like
sort(arrayname,sizeof(array[])/sizeof(array[element0]))

Thanks in advance for any comments/ideas.

j fields
...!ihnp4!islenet!jayf
(Mail) End of article 4894 (of 4956)--what next? [npq]

Article 4895 (61 more) in net.lang.c:
From: [e-mail] (elric)
Subject: Help
Message-ID: <[e-mail]>
Date: 25 Aug 85 01:02:50 GMT
Date-Received: 28 Aug 85 05:03:20 GMT
Reply-To: [e-mail] (Elric of Imrryr)
Organization: Lunatic Laboratories Unltd.
Lines: 13

--MORE--(61%)

 When ever I attempt to compile the Fahrenheit-Celsius table program (on pg
 8 of _The C Programming Language_) I
 get this error:
        "temp.c", line 8: warning: old-fashioned initialization: use =

The line of code is:
                lower = 0;  /* lower limit of temperature */

 Could someone tell me what I'm doing wrong?
    Thanx
     Elric of Imrryr
(Mail) End of article 4895 (of 4956)--what next? [npq]

Article 4896 (60 more) in net.lang.c:
From: [e-mail] (Doug Gwyn <gwyn>)
Subject: Re: Help
Message-ID: <[e-mail]>
Date: 26 Aug 85 01:55:13 GMT
Date-Received: 28 Aug 85 05:27:23 GMT
References: <[e-mail]>
Organization: Ballistic Research Lab
Lines: 15

--MORE--(48%)>  When ever I attempt to compile the Fahrenheit-Celsius table program (on pg
>  8 of _The C Programming Language_) I
>  get this error:
>       "temp.c", line 8: warning: old-fashioned initialization: use =
>
> The line of code is:
>               lower = 0;  /* lower limit of temperature */
>
>  Could someone tell me what I'm doing wrong?

No, because you didn't supply enough information.
The program in the book is okay, so the error must be
in your code.  Check the line or two above where the
compiler detects the problem.  Especially check for
extra/missing { } /* */ ;
(Mail) End of article 4896 (of 4956)--what next? [npq]

Article 4897 (59 more) in net.lang.c:
From: [e-mail] (Peter S. Shenkin)
Newsgroups: net.lang.c,net.unix-wizards
Subject: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 26 Aug 85 13:24:49 GMT
Date-Received: 28 Aug 85 06:35:43 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <>
Reply-To: [e-mail] (Peter S. Shenkin)
Organization: Columbia Univ Biology, New York City
Lines: 27
Summary: I've sometimes bitten myself with MACRO definitions... read on!

--MORE--(43%)I've had several bugs involving code hidden in macro definitions which have
been very difficult to find.  One I recall offhand went something like this:

/* OPEN MOUTH *****************************************************************/#define Coords(I)       (complicated.structure.redirection[I].x, \
                         complicated.structure.redirection[I].y, \
                         complicated.structure.redirection[I].z   )
main()
{
        ...
        subr(Coords(i));  /* BITE */
        ...
}
/***************************************************************************/
subr(x,y,z)
float x,y,z;
{...}
/* SWALLOW ******************************************************************/

Problem is, when expanded, the call to subr looks like
        subr((exp1,exp2,exp3));
The comma operator is applied, and subr() gets only exp1 !!!  The interesting
thing is that if anyone had asked me, whether (something), ((something)),
and (((something))) mean the same in C, I would have said "Yes," without
thinking.  Obviously, I would have been wrong.

Peter S. Shenkin        philabs!cubsvax!peters          Columbia Univ. Biology
(Mail) End of article 4897 (of 4956)--what next? [npq]


Article 4900 (56 more) in net.lang.c:
From: [e-mail]
Subject: Re: No Such Thing
Message-ID: <[e-mail]>
Date: 26 Aug 85 19:59:46 GMT
Date-Received: 28 Aug 85 06:36:48 GMT
Sender: [e-mail]
Lines: 27

--MORE--(42%)> > ... when it comes to defining one's own
> > language extensions, this one seems like a winner:
> >
> >     typedef int     bool;
> >     #define false   0
> >     #define true    1
> >

> Seems like a loser to me. Just takes up space. I actually have to READ
it.

Not really.  You could usually safely assume that if someone is defining
true and false, he/she is defining it as above.  (if some joker decides
to define false as 29 and true as 53, he should be forced for eternity
to covert 10,000-line APL programs to Fortran! :-) )  I think it is much
easier to read things such as:

   done _ true;

than:

   done _ 1;

Of course, explanatory comments in any case improves readability even
more.

Dan
(Mail) End of article 4900 (of 4956)--what next? [npq]

Article 4901 (55 more) in net.lang.c:
From: [e-mail] (x0705)
Subject: Re: Help
Message-ID: <[e-mail]>
Date: 26 Aug 85 15:47:33 GMT
Date-Received: 28 Aug 85 07:09:56 GMT
References: <[e-mail]> <[e-mail]>
Organization: AT&T Bell Labs, Holmdel NJ
Lines: 30

--MORE--(26%)> >  When ever I attempt to compile the Fahrenheit-Celsius table program (on pg
> >  8 of _The C Programming Language_) I
> >  get this error:
> >     "temp.c", line 8: warning: old-fashioned initialization: use =
> >
> > The line of code is:
> >             lower = 0;  /* lower limit of temperature */
> >
> >  Could someone tell me what I'm doing wrong?
>
> No, because you didn't supply enough information.
> The program in the book is okay, so the error must be
> in your code.  Check the line or two above where the
> compiler detects the problem.  Especially check for
> extra/missing { } /* */ ;

The error message you got is normally caused by using constructs that resemble
some of the "old-fashioned" language constructs.  For example:
        foo=-40;
used to mean foo -= 40, instead of foo = (-40).  Several generations of
compilers since then have code to reject "old-fashioned" constructs, even
though they're otherwise perfectly legal.

I this case, I'd check to make sure "lower" has been declared, as a scalar
(int or double?), and that you don't have any more variable declarations after
it.  (Since you can't mix decl.'s and executables, the compiler  may be trying
to get out of a bad situation, and guessing wrong about the error.  Also, as
Doug suggests, watch for extra/missing delimiters.
--
## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
(Mail) End of article 4901 (of 4956)--what next? [npq]

Article 4902 (54 more) in net.lang.c:
From: [e-mail] (Arnold Robbins)
Subject: Re: Cryptic C (YES/NO vs. TRUE/FALSE + other thoughts)
Message-ID: <[e-mail]>
Date: 23 Aug 85 16:57:20 GMT
Date-Received: 28 Aug 85 07:59:39 GMT
References: <[e-mail]>, <[e-mail]> <[e-mail]>
Organization: Pr1mebusters!
Lines: 67
Summary: some thoughts on coding style for binary symbolic values

--MORE--(25%)In article <[e-mail]>, [e-mail] (Henry Spencer) writes:
> >     typedef int     bool;
> >     #define false   0
> >     #define true    1
>
> It's interesting to note that Kernighan&Plauger use "yes" and "no" rather
> than "true" and "false", and my own reaction is that the code often reads
> better that way.  Now that's something to *really* start a raging debate
> about... :-)
> --
>                               Henry Spencer @ U of Toronto Zoology

Well, this can get carried too far.  I have worked with code based on
Software Tools stuff that looks like

        dowrite (file, YES, NO, NO, YES);

Now, can you tell what the heck it is doing? Especially when the code for
dowrite() is 700 lines down in another file? I've often thought that a style
like

#define FORCEWRITE      1
#define NOFORCE         0

#define APPEND          1
#define NOAPPEND        0

        dowrite (file, FORCEWRITE, APPEND, ....);       /* call */

int dowrite (file, force, append,...)   /* actual procedure */
...
{
        if (force)
                ....
        if (append)
                ....
}

is much clearer than the first style.  This is the kind of thing, if anything,
that "enums" would be most useful for (no flames about how poorly enums are
implemented. I'm talking conceptually here.).  Overall, TRUE or FALSE or YES
or NO doesn't make much difference to me.  However, I much prefer the following

        if (boolean)
                something
and

        boolean = (x && y || c >= d);

to the overly verbose

        if (boolean == TRUE)
                something

        if (x && y || c >= d)
                boolean = TRUE;
        else
                boolean = FALSE;

Now *that* should start a really raging debate! :-)
--
Arnold Robbins
CSNET:  arnold@gatech   ARPA:   [e-mail]
UUCP:   { akgua, allegra, hplabs, ihnp4, seismo, ut-sally }!gatech!arnold

Hello. You have reached the Coalition to Eliminate Answering Machines.
Unfortunately, no one can come to the phone right now....
(Mail) End of article 4902 (of 4956)--what next? [npq]

Article 4903 (53 more) in net.lang.c:
From: [e-mail] (Peter da Silva)
Subject: Re: Re:  Assignment in Conditionals
Message-ID: <[e-mail]>
Date: 21 Aug 85 16:12:55 GMT
Date-Received: 28 Aug 85 08:21:36 GMT
References: <[e-mail]> <[e-mail]>
Organization: The Power Elite, Houston, TX
Lines: 21

--MORE--(36%)> A while back, I read a paper from the University of Toronto which
> tested two otherwise "identical" languages - one was expression
> oriented and one statement oriented.  Conclusion: the statement
> oriented one was easier to learn and programming was faster in it.
> The only problem was that the authors weren't sure how much of
> this effect was caused by most other programming languages being
> statement oriented (sorry, I don't have a reference for this -
> it was a CSRG report from U of T).

I think I saw that. It was in CACM or some similar journal... just ran
through my back copies but didn't find it, so either it's not a straight
article, it has a funny title, or I lent it to someone.

That wasn't the only flaw. The other problem was that the two languages
*weren't* otherwise identical, because if they were the statement
oriented one would have been a subset of the expression oriented
one.
--
        Peter (Made in Australia) da Silva
                UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter
                MCI: PDASILVA; CIS: 70216,1076
(Mail) End of article 4903 (of 4956)--what next? [npq]

Article 4904 (52 more) in net.lang.c:
From: [e-mail] (Richard L. Klappal)
Subject: Re: C bites Dog! / project proposal
Message-ID: <[e-mail]>
Date: 27 Aug 85 17:27:52 GMT
Date-Received: 29 Aug 85 00:32:37 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Richard L. Klappal)
Organization: chinet, Public Access UN*X, Chicago
Lines: 43
Keywords: language proposal
Summary:

--MORE--(27%)In article <[e-mail]> [e-mail] (Paul Van de Graaf{|stu) writes:
>I'm ready for something beyond C, and I don't mean C++ or Ada.  If no one
>obliges all just have to do as Jim says and write my own.
>
>Paul van de Graaf      sdcsvax!sdcc3!ee161bep          U. C. San Diego

I have been feeling similarly.  Have been thinking of trying to write
something somewhere between C and PL/I.

1)      Pointers are pointers, not pointers to ..
        (Loses pointer arith, has to be array addressing.  Use
        optimization to reduce common subexpressions to get rid of overhead.
2)      More complete output format control.
        column(n) capability (like F77 Tn, or BASIC TAB(n))

3)      string OPERATORS, not function calls.

4)      discard ++/-- notation.
        keep +=, -=, /=, etc

5)      then .. else .. end / do .. end / do n=1 to n [by nn] while (..)

6)      no assignment in conditionals.
        means duplicating statements, but less confusion about
        .. is he assigning, or did he mean ==, and not catch it.

7)      switch/case statement (or select ..when)

8)      BASED / DEFINED data in stead of unions:  (They sill give me a
        headache.)
10)     conversion functions instead of casts.  They get too unreadable
        too fast.

11)     exception/condition handling ala PL/I.

12)     no ternary operator (cond ? true : false)

13)     I/O defined in the language. Not added as an afterthought like
        Pascal/C/etc.  Will support both stream and record I/O.  Auto
        indexing (ISAM?/B-TREE?/??)) avail.
These are the general specs off the top of my head, and will probably
generate more flames than called for, but I personnaly prefer the
clarity of PL/I to the terseness of C.
(Mail) End of article 4904 (of 4956)--what next? [npq]

Article 4905 (51 more) in net.lang.c:
From: [e-mail] (Chris Torek)
Subject: Re: How do I declare...
Message-ID: <[e-mail]>
Date: 27 Aug 85 10:50:13 GMT
Date-Received: 29 Aug 85 00:45:45 GMT
References: <[e-mail]> <[e-mail]>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 37

--MORE--(31%)It is interesting to note that recursive type definitions make
sense only for function pointers, and only because they have side
effects.  Defining (a pointer to)+ makes no sense, because you can
never do anything with it.  It only points.  You can do an infinite
number of indirections and it still just points.

With function pointers, however, indirecting through them causes
side effects; one such effect can be "terminate this program",
which is the magic clause that makes this useful.

Fascinating.

By the way, note that structure declarations such as

        struct foo {
                struct foo *next;
                ...
        };

are not really recursive.  The inner entity is a pointer to struct
foo, not a struct foo.

Also by the way, the "most portable" declaration for (function
returning pointer to)+ is probably

        <type> *(*(*foo())())()

as this forces the function to return a pointer to a function that
returns a pointer; even if pointers to basic types are of different
sizes, most any compiler will have pointers to "pointer to function
returning pointer to <type>" being the same size as pointers to
"pointer to function returning pointer to function returning pointer
to <type>" and so forth.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept ([phone])
UUCP:   seismo!umcp-cs!chris
CSNet:  chris@umcp-cs           ARPA:   chris@maryland
(Mail) End of article 4905 (of 4956)--what next? [npq]

Article 4906 (50 more) in net.lang.c:
From: [e-mail] (Wayne Throop)
Subject: Re: Cryptic C (YES/NO vs. TRUE/FALSE + other thoughts)
Message-ID: <[e-mail]>
Date: 26 Aug 85 19:26:23 GMT
Date-Received: 29 Aug 85 01:36:59 GMT
References: <[e-mail]>, <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Data General, RTP, NC
Lines: 28

--MORE--(39%)In message 989@gatech, Arnold Robbins gives an interesting example:

> #define FORCEWRITE    1
> #define NOFORCE               0
>
> #define APPEND                1
> #define NOAPPEND      0
>
>       dowrite (file, FORCEWRITE, APPEND, ....);       /* call */
>
> int dowrite (file, force, append,...) /* actual procedure */

I like this notion in general, but I point out a problem with it that a
(currently nonexistant) lint-like tool could help with.  What if the
call was done like so:

    dowrite( file, NOAPPEND, FORCEWRITE, ... );

This doesn't do remotely what you intend, and it very hard to detect.
What you "really want" is to be able to declare two enumerations, and
make lint check that you don't pass members of one enumeration to a
formal of another type.

Also, the "extra checking" that K&R says that lint-like tools are free
to do with typedefs would be welcome.  No current link (that I am aware
of) will allow using typedef as a type abstraction device.
--
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw
(Mail) End of article 4906 (of 4956)--what next? [npq]

Article 4907 (49 more) in net.lang.c:
From: [e-mail] (BlandMA)
Subject: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 28 Aug 85 19:18:18 GMT
Date-Received: 30 Aug 85 01:36:24 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <> <[e-mail]>
Organization: AT&T Information Systems Laboratories, Denver
Lines: 7

--MORE--(75%)I was amused when I realized why this statement didn't print anything:

        printf("toggle ">" verbosity\n");

--
Alan Bland     {ihnp4|allegra}!druca!mab
AT&T Information Systems, Denver CO
(Mail) End of article 4907 (of 4956)--what next? [npq]

Article 4908 (48 more) in net.lang.c:
From: [e-mail] (Curtis Jackson)
Newsgroups: net.bugs.usg,net.lang.c,net.unix-wizards
Subject: SVR2 (at least) printf bug
Message-ID: <[e-mail]>
Date: 28 Aug 85 19:42:51 GMT
Date-Received: 30 Aug 85 01:51:39 GMT
Reply-To: [e-mail] (Curtis Jackson)
Organization: AT&T Technologies, Burlington NC
Lines: 40

--MORE--(27%)This bug is known to the Unix Hotline and the appropriate PIC (People
In Charge), but wasn't known to me so I thought I'd share it.

If you open a file for simple update (mode "r+" on fopen), then read
some stuff in the file, then try to write on the file, the writes
will appear to work perfectly (printf returns good bytecounts and
everything), but no writes will take place in the real world.

This happens because the code to check for _IORW (read/write permissions)
is wrong in printf.c, fprintf.c, vprintf.c, and vfprintf.c.  This
causes the write permissions (_IOWRT) turnon code to be skipped and
_doprnt() returns a negative number; so the _cnt field in the FILE
descriptor decrements rather than increments, and the fflush() therefore
has no effect -- thus silently no writes.

The errant lines are:

        if (!(stdout->_flag | _IOWRT)) {
                /* if no write flag */
                if (stdout->_flag | _IORW) {

since |'ing with a constant is not a very good idea, change them to &'s:

        if (!(stdout->_flag & _IOWRT)) {
                /* if no write flag */
                if (stdout->_flag & _IORW) {

and everything works fine.

I found this bug very interesting to track down since (apparently) the
initial modes on the file are both _IOWRT and _IORW.  This means that
if you just write a file fopened with "r+" everything works, but the
first read turns off _IOWRT and any subsequent writes silently fail.

Don't forget to remake the library!!
--

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson   ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
                        ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
(Mail) End of article 4908 (of 4956)--what next? [npq]

Article 4909 (47 more) in net.lang.c:
From: [e-mail] (Gary M. Samuelson)
Subject: Re: Re: C bites (Null loop-bodies)
Message-ID: <[e-mail]>
Date: 27 Aug 85 15:26:09 GMT
Date-Received: 30 Aug 85 02:12:01 GMT
References: <[e-mail]> <[e-mail]>
Distribution: net
Organization: Bunker Ramo, Trumbull Ct
Lines: 16

--MORE--(64%)>       I put null loop-bodies on a separate line like in the following
> example.
>
>               while (eatup() != '\n')
>                       ;

Putting the semi-colon on a separate line does help make it clear
that the body of the loop is intentionally null, but what I like
even better is:

                while( eatup() != '\n' )
                        continue;

Comments?

Gary Samuelson
(Mail) End of article 4909 (of 4956)--what next? [npq]

Article 4910 (46 more) in net.lang.c:
From: [e-mail] (Joe Mueller)
Subject: Re: Re: How do I declare...
Message-ID: <[e-mail]>
Date: 26 Aug 85 23:46:18 GMT
Date-Received: 30 Aug 85 02:18:21 GMT
References: <[e-mail]> <[e-mail]>
Organization: NSC Portland Development Center, Portland Oregon
Lines: 23

--MORE--(33%)> Thus, if you want an array of pointers to arrays of pointers, you can't
> do it.  Nor can you declare functions returning pointers to functions.

You have to be kidding, you can declare both of these things although the
syntax may be a little weird.

Here's an array of 5 pointers to arrays of 6 pointers to char
        char *(*foo[5])[6]      /* how do you like that sports fans! */

Here's a function returning a pointer to a function returning an int
        int (*foo())()

If you have trouble declaring things or deciphering existing code, I highly
recommend a utility called "cdecl". It takes an english description of what
you want and gives you the C syntax for it, it will also take a C declaration
and translate it to an english description of what it is. I used it on the
above examples so I got the declaration right the first time with minimal fuss.
It has been posted to the net at least once before, if you absolutely can't
find it elsewhere and you want a copy, I'll send it to you. If too many people
need it, I'll post it to the net.

The language has hooks to declare incredibly complex data structures, if your
compiler can't hack it, it's not the language's fault.
(Mail) End of article 4910 (of 4956)--what next? [npq]

Article 4911 (45 more) in net.lang.c:
From: [e-mail] (Rick Genter)
Subject: How to declare a pointer to function returning pointer to function
Message-ID: <[e-mail]>
Date: 27 Aug 85 13:35:42 GMT
Date-Received: 30 Aug 85 02:38:39 GMT
Organization: Automatix, Inc., Billerica, MA
Lines: 23

--MORE--(44%)
     I couldn't resist trying this.  Cdecl claims no problem declaring
something to be a pointer to a function returning a pointer to a function
returning int:

Script started on Tue Aug 27 09:27:43 1985

% cdecl
declare x as pointer to function returning pointer to function returning int
int (*(*x)())()
%

Script done on Tue Aug 27 09:28:32 1985

     No, that's not lisp ... :-)

                                        - reg
                                        Rick Genter
                                        Automatix Inc.
                                        ...!decvax!encore!vaxine!reg

(Note: As of next week (9/3/85) I will be at BBN Labs.  I don't know what my
       new electronic address will be).
(Mail) End of article 4911 (of 4956)--what next? [npq]

Article 4912 (44 more) in net.lang.c:
From: [e-mail] (ben)
Subject: Xinu Applications: any experience??
Message-ID: <[e-mail]>
Date: 27 Aug 85 16:38:14 GMT
Date-Received: 30 Aug 85 02:47:45 GMT
Organization: CERN, Geneva/Switzerland
Lines: 8

--MORE--(66%)
  Does anyone out there have experience of making PRACTICAL
applications using Douglas Comer's Xinu system?  We are
interested particularly in any real-time applications for
68000's.

   Ben M. Segal,  CERN-DD,  1211 Geneva 23,  Switzerland
                  (ben@cernvax via mcvax)
(Mail) End of article 4912 (of 4956)--what next? [npq]

Article 4913 (43 more) in net.lang.c:
From: [e-mail] (Stephen Humble)
Subject: Re: Help
Message-ID: <[e-mail]>
Date: 28 Aug 85 18:09:48 GMT
Date-Received: 30 Aug 85 03:44:30 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Stephen Humble)
Organization: MIT, Cambridge, MA
Lines: 15
Summary: hyphen in function name?

--MORE--(57%)Sender:

[DO THE RIGHT THING]

>       "temp.c", line 8: warning: old-fashioned initialization: use =

This has happened to me too, and it's usually because I put a hyphen
in the function's name, so cc thinks I want to subtract one part of
the name from the other part, or something equally absurd. Hyphens in
declarators are a no_no. :-)
cc is notorious for not telling you that an error has occurred until
several lines after the actual error.
(Mail) End of article 4913 (of 4956)--what next? [npq]

Article 4914 (42 more) in net.lang.c:
From: driehuis%hlerul5.BITNET@Berkeley
Subject: Re: Re: Re: C bites (Null loop-bodies)
Message-ID: <[e-mail]>
Date: 28 Aug 85 18:22:45 GMT
Date-Received: 31 Aug 85 02:11:51 GMT
Sender: [e-mail]
Lines: 31

--MORE--(32%)Gary M. Samuelson <[e-mail]> writes:
>>     I put null loop-bodies on a separate line like in the following
>> example.
>>
>>         while (eatup() != '\n')
>>             ;
>
>Putting the semi-colon on a separate line does help make it clear
>that the body of the loop is intentionally null, but what I like
>even better is:
>
>        while( eatup() != '\n' )
>            continue;
>
>Comments?
Yes. I am not fond of using continue if it is not necessary
to do so. All loop-modyfying statements require an additional
effort to read - at least, for me.
Neither do I like the suggesion I saw in info-c, that read
something like
>        while (function() != READY) {
>             }
The reason why is quite prosaic: when I edit an existing
file into something else, with cutting, pasting, and deleting,
sometimes (no more than once a week :=)) a line or even a
block of text gets lost, leaving embraced white space.
My first reaction to seeing braces, embracing nothing, is: oops...
been too hastily with the delete-line key.
The convention to use a period on a line by itself is
sufficient to recognise at first sight: "this is a null
statement".
(Mail) End of article 4914 (of 4956)--what next? [npq]

Article 4915 (41 more) in net.lang.c:
From: [e-mail] (Chris Torek)
Subject: Re: Help
Message-ID: <[e-mail]>
Date: 28 Aug 85 15:16:49 GMT
Date-Received: 31 Aug 85 02:13:19 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 36

--MORE--(34%)> > > When ever I attempt to compile the Fahrenheit-Celsius table
> > > program (on pg 8 of _The C Programming Language_) I get this error:
> > >   "temp.c", line 8: warning: old-fashioned initialization: use =

> The error message you got is normally caused by using constructs
> that resemble some of the "old-fashioned" language constructs.

Right so far...

> For example:
>       foo=-40;
> used to mean foo -= 40, instead of foo = (-40).

This is true, but not directly related to the actual error given above.

> I this case, I'd check to make sure "lower" has been declared, as
> a scalar (int or double?), and that you don't have any more variable
> declarations after it.

The problem is one of two things.  The Portable C Compiler has seen
either

        <type> <variable> <constant>

or

        <type> <variable> {

when it gives the "warning: old-fashioned initialization: use ="
error message.  (The next message may well be "syntax error".)
One of the rather neat things you can do is run "cc -E" on the
source file, to see what's actually being compiled.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept ([phone])
UUCP:   seismo!umcp-cs!chris
CSNet:  chris@umcp-cs           ARPA:   chris@maryland
(Mail) End of article 4915 (of 4956)--what next? [npq]

Article 4916 (40 more) in net.lang.c:
From: [e-mail] (Chris Torek)
Subject: Re: How to declare a pointer to function returning pointer to function
Message-ID: <[e-mail]>
Date: 28 Aug 85 15:19:44 GMT
Date-Received: 31 Aug 85 02:13:27 GMT
References: <[e-mail]>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 12

--MORE--(55%)> I couldn't resist trying this.  Cdecl claims no problem declaring
> something to be a pointer to a function returning a pointer to a
> function returning int:

There *is* no problem declaring that.  The problem is declaring a
function returning a pointer to a function returning a pointer to
a function returning a pointer to a ..., ad infinitum.  *There is
no base type in the definition*.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept ([phone])
UUCP:   seismo!umcp-cs!chris
CSNet:  chris@umcp-cs           ARPA:   chris@maryland
(Mail) End of article 4916 (of 4956)--what next? [npq]

Article 4917 (39 more) in net.lang.c:
From: [e-mail] (Ken Arnold%CGL)
Subject: Re: C bites Dog!
Message-ID: <[e-mail]>
Date: 28 Aug 85 19:11:11 GMT
Date-Received: 31 Aug 85 02:40:47 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Ken Arnold)
Organization: UCSF Computer Graphics Lab
Lines: 31

--MORE--(30%)In article <[e-mail]> [e-mail] (Paul Van de Graaf) writes:
>Action also has the if <> then <> fi style bracketing which I suppose was
>inspired by the Bourne shell.  I personally don't like the case .. esac stuff
>in the Bourne shell, but I can't understand why C programmers are so concerned
>about typing 2 to 5 letter keywords instead of (, ), {, and }.  I don't type
>special characters very well, and I think it's because of having to hit that
><shift> key.

To me it is not a question of typing, but a question of bandwidth.
Keywords look a lot like variables unless read, whereas symbols don't
look like variables at all.  The extreme examples are something like

        add a to b and assign to c

                vs.

        c = a + b

where the second is clearly more legible.  This can be taken to
extremes, of course, but I still find that it is easier to scan a
language which uses a reasonably rich token set instead of a lot of
keywords.  Once you learn such a set of symbols, it seems easier to
read quickly, probably because the bandwitdh of communication is
higher, and operators are quickly visible as operators, as distinct
from programmer-defined tokens.

How easy a language is to type seems relatively unimportant compared to
other factors, including legibility.  APL is reasonably easy to
*type*...

                Ken Arnold
(Mail) End of article 4917 (of 4956)--what next? [npq]

Article 4918 (38 more) in net.lang.c:
From: [e-mail] (Scott Pace)
Subject: Re: How do I declare...
Message-ID: <[e-mail]>
Date: 27 Aug 85 18:39:58 GMT
Date-Received: 31 Aug 85 03:38:08 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Scott Pace)
Organization: Philips Information Systems - St. Laurent  P.Q., Canada
Lines: 49

--MORE--(34%)>> Either I'm missing the perfectly obvious or I've found something
>> that's impossible to declare in C, even though it makes sense.

>You have discovered a fundamental flaw in C type notation.  In essence,
>C allows recursive types only in structs, unions, and enums (and I'm not
>sure how it would be usefull in enums, so that one can be ruled out for
>practical purposes).
>
>Thus, if you want an array of pointers to arrays of pointers, you can't
>do it.  Nor can you declare functions returning pointers to functions.


Well, our compiler seems to handle these sort of constructs ok:-

looking at an array of pointers to arrays of pointers first...

int *(*foo1[10])[];

here foo1 is an array of pointers, each pointer pointing to an array
of pointers to int's.
Thus an integer element might be accessed as follows:

*(*foo1[1])[2] and another way might be **foo1[0]


now looking at functions returning pointers to functions:-

int *(*func1())();

here func is a function returning a pointer to a function, and this
function returns a pointer to an int.
Thus you could do things like:

int *(*func2)(); /*pointer to a function returning a pointer to int*/
int *x;
.
.
.
func2 = func1();
x = (func2)();
.
.
etc.

Cheers

        Scott Pace, ...!philabs!micomvax!othervax!scott

(I hope I got all that right!!!)
(Mail) End of article 4918 (of 4956)--what next? [npq]

Article 4920 (36 more) in net.lang.c:
From: [e-mail] (Tim Smith)
Newsgroups: net.lang.c,net.micro.mac
Subject: Re: help with sizeof() in HIPPO-C
Message-ID: <[e-mail]>
Date: 27 Aug 85 00:22:46 GMT
Date-Received: 31 Aug 85 06:00:52 GMT
References: <[e-mail]>
Distribution: net
Organization: Callan Data Systems, Westlake Village, CA
Lines: 27

--MORE--(41%)> Just discovered that there does not seem to be a sizeof() function
> in Hippo C level I or II.  This would sure be useful for passing

Level I was written in Pasadena, and when I was bored, I would go over
and hassle them about things I thought they were doing wrong.  I don't think
I would have missed a lack of sizeof.  Also, we once ran a set of C progrs
meant to test out pcc through Hippo level I, and there must have been
a sizeof in there somewhere!  ( no - I can't tell anyone where to get
the set of test programs. ).

Anyway, try all of the following, since I am not sure how they handle
builtin functions like sizeof -- they may have fucked up the parsing:

        sizeof x ;              /* where x is a variable */
        sizeof(x) ;
        sizeof( x ) ;
        sizeof (x) ;
        sizeof ( x ) ;
        sizeof(int) ;
        sizeof( int ) ;
        sizeof (int) ;
        sizeof ( int ) ;

If none of these work, give them a call.
--
                                        Tim Smith
                                ihnp4!{cithep,wlbr!callan}!tim
(Mail) End of article 4920 (of 4956)--what next? [npq]


Article 4922 (34 more) in net.lang.c:
From: [e-mail] (Frank Adams)
Subject: Re: Cryptic C (YES/NO vs. TRUE/FALSE + other thoughts)
Message-ID: <[e-mail]>
Date: 27 Aug 85 03:01:24 GMT
Date-Received: 31 Aug 85 09:52:38 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 33
Summary: Aggregates are even better

--MORE--(42%)
In article <[e-mail]> [e-mail] (Arnold Robbins) writes:
>
>Well, this can get carried too far.  I have worked with code based on
>Software Tools stuff that looks like
>
>       dowrite (file, YES, NO, NO, YES);
>
>Now, can you tell what the heck it is doing? Especially when the code for
>dowrite() is 700 lines down in another file? I've often thought that a style
>like
>
>#define FORCEWRITE     1
>#define NOFORCE                0
>
>#define APPEND         1
>#define NOAPPEND       0
>
>       dowrite (file, FORCEWRITE, APPEND, ....);       /* call */
>
>
>is much clearer than the first style.  This is the kind of thing, if anything,
>that "enums" would be most useful for (no flames about how poorly enums are
>implemented. I'm talking conceptually here.).

The problem with your solution is I can just easily write

        dowrite(file, APPEND, NOFORCE, ...)

and will have a terrible time finding the error.  This is where Ada wins:

        dowrite(file, append=>true, force=>false, ...)

is clear, simple, and error-resistant.
(Mail) End of article 4922 (of 4956)--what next? [npq]

Article 4923 (33 more) in net.lang.c:
From: [e-mail] (eric)
Subject: Re: VAX VMS C / UNIX C Compatibility -- Need Info
Message-ID: <[e-mail]>
Date: 27 Aug 85 16:50:32 GMT
Date-Received: 31 Aug 85 09:53:03 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Brookhaven National Lab. Upton, N.Y.
Lines: 19

--MORE--(41%)> > VMS is very record-ish, while stream i/o is the unix thing. Unfortunately,
> > port didn't work because we didn't really spend the effort required to do
> > the QIO's required to fake stream i/o on VMS.
>

A year or two ago, I wrote a xmodem protocol program for VMS and
UNIX in C.  The effort required to set up the raw state in both OS's
was equivalent.  Doing these things on VMS takes no more effort
than finding the appropriate ioctl function codes on UNIX.  When
it got to doing the reads byte by byte with timeouts, VMS was
much simpler than UNIX.  Under VMS, just one function call was
able to read n characters returning an error if more than t
seconds elapsed between characters.  Under UNIX, it was a complicated
mess with two functions, alarms, longjmps and extra buffering.

                                                Eric G. Stern
                                                [e-mail]
                                                [e-mail]
                                                ...!philabs!sbcs!bnl!stern
(Mail) End of article 4923 (of 4956)--what next? [npq]

Article 4924 (32 more) in net.lang.c:
From: [e-mail] (Wayne Throop)
Subject: Re: How do I declare... (I knew that!)
Message-ID: <[e-mail]>
Date: 29 Aug 85 17:20:55 GMT
Date-Received: 2 Sep 85 04:18:33 GMT
Organization: Data General, RTP, NC
Lines: 27

--MORE--(28%)I have been inundated with a flood of postings and mail saying "you
can so declare a pointer to a function returning a pointer to a
function".  I started replying by mail, but this proves impractical due
to volume.  Let me introduce my defense as I did in the first letter I
sent out:

"Aaaarrrrgggghhhh!"

There.  I feel better now.  I really *did know* that you can declare
pointers to arrays of pointers to arrays (of primitive types), and
pointers to functions returning pointers to functions (returning
primitive types).  I thought it was clear from the context that I meant
that it is impossible to declare a pointer to a function returning
pointer to function *of that function's own type*.  But noooooooo!  All
you nit-pickers assumed I meant what I said!  Sheeesh!   :-)

In any event, I still maintain that C's type notation is deficent, in
that it only allows recursion in declarations of structs, unions, and
enums (and I haven't found a use for recursion in enums).  It does *not*
allow recursion in type declaractions that contain only pointer,
function, or array constructs.

If you wish to show me the error of my ways, mail or post a typedef F
of a pointer-to-function-returning-type-F.  My claim is that C allows no
such constructs, and that this lack is a shortcoming of the C language.
--
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!rtp47!throopw
(Mail) End of article 4924 (of 4956)--what next? [npq]

Article 4925 (31 more) in net.lang.c:
From: [e-mail] (Stew Rubenstein)
Subject: Re: Cryptic C (YES/NO vs. TRUE/FALSE + other thoughts)
Message-ID: <[e-mail]>
Date: 31 Aug 85 02:12:58 GMT
Date-Received: 2 Sep 85 05:34:43 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Stew Rubenstein)
Organization: Aiken Computation Laboratory, Harvard
Lines: 32
Summary:

--MORE--(36%)In article <[e-mail]> [e-mail] (Frank Adams) writes:
>
>In article <[e-mail]> [e-mail] (Arnold Robbins) writes:
>
>  >Well, this can get carried too far.  I have worked with code based on
>  >Software Tools stuff that looks like
>  >
>  >    dowrite (file, YES, NO, NO, YES);
>...
>  >    dowrite (file, FORCEWRITE, APPEND, ....);       /* call */
>  >
>  >
>  >is much clearer than the first style.  This is the kind of thing, if
>  >anything, that "enums" would be most useful for (no flames about how poorly
>  >enums are implemented. I'm talking conceptually here.).
>
>The problem with your solution is I can just easily write
>
>       dowrite(file, APPEND, NOFORCE, ...)
>
>and will have a terrible time finding the error.  This is where Ada wins:
>
>       dowrite(file, append=>true, force=>false, ...)

In a perfect world, the argument types for dowrite() would be declared
as different enum types and the compiler will complain if you mix them
up (i.e. in new ANSI C if I understand it right).  In a slightly less
perfect world, lint would complain about the inconsistency.  We were
talking conceptually, right?  Not to say that the keyword style isn't
better, but this is one the compiler ought to catch.

Stew
(Mail) End of article 4925 (of 4956)--what next? [npq]

Article 4926 (30 more) in net.lang.c:
From: [e-mail]
Subject: Re: Re: c programming style - READ THIS
Message-ID: <[e-mail]>
Date: 28 Aug 85 19:12:00 GMT
Date-Received: 2 Sep 85 05:36:39 GMT
References: <[e-mail]>
Lines: 9

--MORE--(54%)
Since 'p+n', where p is a pointer and n is an integer, is equivalent to
adding n*sizeof(whatever p points to), the safe and portable way of adding
an integer to a pointer treated as an integer is
         (char *)p + n
since (I think) character are always a byte wide.  If that's not always the
case, I apologize; on the other hand, it's probably safe than converting
a pointer to an int or a long;  I had trouble porting something from a VAX
to a Pyramid because of a cast of this sort.
(Mail) End of article 4926 (of 4956)--what next? [npq]

Article 4928 (28 more) in net.lang.c:
From: [e-mail]
Subject: Re: What does the compiler think I am do
Message-ID: <[e-mail]>
Date: 30 Aug 85 12:43:00 GMT
Date-Received: 2 Sep 85 05:37:23 GMT
References: <[e-mail]>
Lines: 15

--MORE--(46%)


There is no such thing as an "assignment statement" in C.  Rather, assignment
is just one more binary operator, and the language supports the "expression
statement".  What you have written, c - a;, is just another expression
statement, that merely has no side effects.  According to the Unix philosophy,
this is perfectly ok, and (if you have a PCC compiler) it probably generates
the code to load up the values and do the subtract (why? beacause you asked
it to).  Hence lint.  Lint will also warn you about using = in conditionals
where you might have meant ==.

            --Darryl Richman, INTERACTIVE Systems Corp.
            ...!cca!ima!ism780!darryl
            The views expressed above are my opinions only.
(Mail) End of article 4928 (of 4956)--what next? [npq]

Article 4929 (27 more) in net.lang.c:
From: [e-mail] ( Joel Coltoff)
Subject: Re: Re: C bites (Null loop-bodies)
Message-ID: <[e-mail]>
Date: 30 Aug 85 14:55:30 GMT
Date-Received: 2 Sep 85 05:43:25 GMT
References: <[e-mail]>
Organization: System Development Corporation, Paoli PA
Lines: 10

--MORE--(73%)<<>>

My approach is to explicitly spell it out with a comment. Sometimes they
are the only comments in the program

        while ( eatup() != '\n' )
                /* NULL BODY */;

        - Joel Coltoff
        {prseby,sdcrdcf,psuvax1}!burdvax!coltoff
(Mail) End of article 4929 (of 4956)--what next? [npq]

Article 4930 (26 more) in net.lang.c:
From: [e-mail] (Peter da Silva)
Subject: Re: C bites Dog!
Message-ID: <[e-mail]>
Date: 30 Aug 85 18:09:30 GMT
Date-Received: 2 Sep 85 05:44:17 GMT
References: <[e-mail]> <[e-mail]>
Organization: Information Brokerage Network, Houston, TX
Lines: 11

--MORE--(53%)> > > > >               if (sv > score);   <----- note extraneous semi-colon
> > > > >                       score = sv;
> > > ICK ICK ICK! I hate languages that do that. Ever considered using "cb" as a
> > > debugging tool? I have an MS-DOS version if anyone wants it...
> > [...]  What
> > would you do, compare the output of `cb' with the original? Takes
> > lots of time & can be visually overlooked.

Yes. Since I write cb-like code in the first place it's very easy to just
diff it... any lines diff catches are either long function calls or errors
of this type.
(Mail) End of article 4930 (of 4956)--what next? [npq]

Article 4931 (25 more) in net.lang.c:
From: [e-mail] (Guy Harris)
Newsgroups: net.lang.c,net.unix-wizards
Subject: Re: Re: how has C bitten you?
Message-ID: <[e-mail]>
Date: 31 Aug 85 04:36:43 GMT
Date-Received: 2 Sep 85 05:47:08 GMT
References: <[e-mail]> <[e-mail]>, <[e-mail]> <[e-mail]>
Organization: Sun Microsystems, Inc.
Lines: 46

--MORE--(32%)> Not really a bite, but I remember when I was first learning C
> I was quite bewildered by the fact that you couldn't really
> declare your own 'argv', that is, you couldn't declare an
> array of pointers to fixed length buffers except perhaps by:
>
> char *myargv[] = {
>       "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
>       "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
>
>       etc
>
> I mean, argv seemed kinda holy to me, disturbing.

If you want an array of pointers to fixed-length buffers, you can declare it
as long as the number of such pointers can be determined at the time you
write the code.

        char bufs[3][20];

        char *bufps[3] = {
                bufs[0],
                bufs[1],
                bufs[2],
        };

If the number can't be fixed when you write the code, you can set up "bufps"
at run time.

Also note that "argv" isn't a pointer to an array of pointers to fixed-length
buffers, it's a pointer to an array of pointers to strings, which you *can*
declare.

> P.S. I know argv is var length, but that would be even harder to declare!

The secret is that "argv" (or, more correctly, what "argv" points to)
*isn't* declared.  Pointers need not point to things which have been
declared; "malloc" returns pointers to objects fabricated on the fly.  If
you have "n" arguments ("n" is a variable here), just do

        register char **argv;

        argv = (char **)malloc(n * sizeof(char *));

And you can fill them in.

        Guy Harris
(Mail) End of article 4931 (of 4956)--what next? [npq]

Article 4932 (24 more) in net.lang.c:
From: [e-mail] (Doug Pardee)
Subject: Re: Order of evaluation
Message-ID: <[e-mail]>
Date: 30 Aug 85 18:01:29 GMT
Date-Received: 2 Sep 85 06:13:44 GMT
References: <[e-mail]>
Organization: Calcomp Display Products Division, Scottsdale, AZ, USA
Lines: 17

--MORE--(41%)> >OK, I understand that order of evaluation is not guaranteed.  I assume that
> >was done to make compilers easier to write.  Is there any other reason?  Does> >it really make compilers easier to write?
>
> Also, allowing the compiler to reorder the expression within certain
> limits allows it to do some optimizations. Most code is not affected by
> order of evaluation, and C does allow an order to be forced (by assigning
> an explicit temporary), so I think this is very reasonable.

What drives me up a wall is that C does *not* allow an order to be
forced by using parentheses!  The compiler is at liberty to ignore
parens which group operators of the same precedence.  <e.g. a+(b+c)>

I don't think much of the notion of having to store intermediate results
just to get the correct answer.
--
Doug Pardee -- CalComp -- {seismo!noao,decvax!noao,ihnp4}!terak!doug
(Mail) End of article 4932 (of 4956)--what next? [npq]

Article 4933 (23 more) in net.lang.c:
From: [e-mail] (Kee Hinckley)
Subject: Wanted: Info on C Interpreters
Message-ID: <[e-mail]>
Date: 29 Aug 85 17:45:43 GMT
Date-Received: 2 Sep 85 06:22:21 GMT
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 23

--MORE--(37%)<now you c me now you don't>

I'm looking for any information anyone can give me on C interpreters,
primarily ones that run on Unix, but info on others is welcome.  In
particular I'd like to know:

    Who makes it?
    What is it written in?
    How does it work (pcode, trees...)?
    How good is it?
    And of course...  How much does it cost?
    And anything else you'd like to add.


                                            Kee Hinckley
                                            [phone]
                                            ...decvax!wanginst!apollo!nazgul


The views expressed herein are not necessarily those of Apollo Computer, since
views are naturally expressed in a block structured environment.  Apollo forms
the containing block in which I reside, but the views expressed herein are all
in local variables that temporarily override any views help by Apollo Computer.
(Mail) End of article 4933 (of 4956)--what next? [npq]

Article 4934 (22 more) in net.lang.c:
From: [e-mail] (COTTRELL, JAMES)
Subject: This Sentence is False
Message-ID: <[e-mail]>
Date: 30 Aug 85 01:20:41 GMT
Date-Received: 2 Sep 85 06:25:09 GMT
Sender: [e-mail]
Lines: 97

--MORE--(12%)/* Fiercely I go into battle:
> I have always thought that to be a machine dependancy (the value of true and
> false).  Maybe I'm wrong.  But, different machines DO have different ideas
> of which is true and false (at the assembler level).  And it is simply
> a convention.

Machines have no concept of truth. They can determine if a condition
(equality, greater than, negative, overflow, etc.) exists and then
*dynamically* alter the course of their control flow. But no machine
I know of has a `branch if true' instruxion. Note I am not talking
about the abstraxion a la 68k where an unconditional branch is named
`branch if true' & the converse is called `branch if false'. I am
talking about a *conditional* `branch if true'.

> Still though, #define TRUE (1==1) is very obvious, to the point, correct,
> proper, and all sorts of things.  And it doesn't require one to know
> that detail about C that the convention is ~0 == TRUE and 0 == FALSE.

Your attention span must be even shorter than mine. (What were we talking
about :-) If you are consistant, ignorance is bliss. But what about
fred's code over there, if (p). Hmmmm, now what does that do?

> But C gives you all these operators which allow you to define things
> machine independantly rather than hardcoding values.  Obviously I mean
> casts and the sizeof operator.  Also arithmetic to pointers.  So why not
> TRUE and FALSE?
> --- David Herron

Because who needs them? Integers do quit well, thank you.
On to my next victim.

> Not really.  You could usually safely assume that if someone is defining
> true and false, he/she is defining it as above.  (if some joker decides
> to define false as 29 and true as 53, he should be forced for eternity
> to covert 10,000-line APL programs to Fortran! :-) )

Agreed. But it's not 29 & 53 were talking about now is it? Zero & One
have certain useful mathematical properties, described below.

> I think it is much easier to read things such as:
>
>    done = true;
>
> than:
>
>    done = 1;

How about `done++'. Most variables are initialized to false. It's
kinda like reality, nothing can be taken for granted (default false)
unless it appears to be true.

> Of course, explanatory comments in any case improves readability even
> more.
> Dan Howell

Most definitely. Now for the last one:

> To me, the mapping TRUE -> 0 and FALSE -> non-zero doesn't seem obvious,
> and I'm sure it isn't to most programmers who ever worked in assembler.
> In assembler, one often writes the following (I'm using pseudocode
> rather than any particular assembler):
>
>       compare two values
>       jumpto stuff  if zero
>
> Which is the assembler equivalent of
>
>         if (value1 == value2)
>         <do stuff> ;

I think you've got it backwards.

> When I was in high school I was programming TRS-80's in both assembler
> and BASIC, and I had lots of trouble remembering whether BASIC
> represented truth as zero or -1.  No such memory is needed for the
> assembler, of course, since comparison is merely done by subtraction (a
> compare instruction is usually just a subtract instruction that doesn't
> store the result anywhere), so it is obvious what the zero indicator
> means.  It is not so obvious to me that in C 0 should mean false and 1
> mean true.
> --
>     Barry Margolin
>     ARPA: barmar@MIT-Multics
>     UUCP: ..!genrad!mit-eddie!barmar

Ah but it is! Consider the mathematical implications of it! The MAX
funxion is just the expression `(A > B) * A + (A < B) * B'. APL, which
was designed by a mathematician, uses the exact same concept. The
idea of `P implies Q' can be written as `P <= Q'! There have been many
different *conventions* used in many languages to represent the
*hidden* boolean values, sometimes differing between implementations.
I think time will show that APL & C do it the best way. At least the
cat's out of the bag & everybody knows what the spots look like.

        jim             cottrell@nbs
*/
------
(Mail) End of article 4934 (of 4956)--what next? [npq]

Article 4935 (21 more) in net.lang.c:
From: [e-mail] (COTTRELL, JAMES)
Subject: I Do Declare!
Message-ID: <[e-mail]>
Date: 29 Aug 85 22:09:59 GMT
Date-Received: 2 Sep 85 06:51:46 GMT
Sender: [e-mail]
Lines: 41

--MORE--(29%)/*
In article <[e-mail]> [e-mail] writes:
> Either I'm missing the perfectly obvious or I've found something
> that's impossible to declare in C, even though it makes sense.  I'm
> trying to implement a simple finite state machine with states
> represented by C functions.  Each state function would accept some
> input value as an argument and return a pointer to the function
> implementing the next state...

Cheat! Declare your variable as a pointer to funxion returning int
(or char (or void) pointer for sticklers) and then use casts.
Saves a lot of headaches trying to figure out all those types.
With char or void pointers, there ought to be a portable way.

typedef int      (*PFI)();
typedef char    *(*PFCP)();     /* for portability sticklers */
typedef void    *(*PFVP)();     /* if available */

int     other();
int     init();                 /* initial func */
PFI     state = init;           /* state var */

init(arg)
{
        state = other;          /* no problem to set directly */
        ...
        return((int)state);     /* to return we must cast */
        ...
        state = (PFI)other(arg);/* must cast to assign */
        ...
        (*state)(arg);          /* can be called directly */
        ...
        while (state = (PFI)(*state)(arg));     /* until no more funx */
}

Once in a while you get shown the light
In the strangest of places if you look at it right.

        jim             cottrell@nbs
*/
------
(Mail) End of article 4935 (of 4956)--what next? [npq]

Article 4936 (20 more) in net.lang.c:
From: [e-mail] (Doug Gwyn <gwyn>)
Subject: Re: C bites Dog! / project proposal
Message-ID: <[e-mail]>
Date: 29 Aug 85 18:48:51 GMT
Date-Received: 2 Sep 85 06:56:25 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Ballistic Research Lab
Lines: 9

--MORE--(60%)Judging by rlk's language proposal, he doesn't like those things
that C lovers think are C's greatest advantages.  He is certainly
entitled to his opinion (and his own language), so I hope we can
avoid zillions of return flames on this.

> ... but I personnaly prefer the clarity of PL/I to the terseness of C.

Besides, what can one say to a person who thinks PL/I is
distinguished by its clarity?
(Mail) End of article 4936 (of 4956)--what next? [npq]


Article 4938 (18 more) in net.lang.c:
From: [e-mail] (COTTRELL, JAMES)
Subject: Array Declarations
Message-ID: <[e-mail]>
Date: 29 Aug 85 19:07:54 GMT
Date-Received: 2 Sep 85 06:57:00 GMT
Sender: [e-mail]
Lines: 1

--MORE--(98%)------
(Mail) End of article 4938 (of 4956)--what next? [npq]

Article 4939 (17 more) in net.lang.c:
From: [e-mail] (COTTRELL, JAMES)
Subject: Array Declarations
Message-ID: <[e-mail]>
Date: 29 Aug 85 20:04:51 GMT
Date-Received: 2 Sep 85 06:59:11 GMT
Sender: [e-mail]
Lines: 42

--MORE--(25%)/*
> Not really a bite, but I remember when I was first learning C
> I was quite bewildered by the fact that you couldn't really
> declare your own 'argv', that is, you couldn't declare an
> array of pointers to fixed length buffers except perhaps by:
>
> char *myargv[] = {
>       "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
>       "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
>
> I mean, argv seemed kinda holy to me, disturbing.
>
>       -Barry Shein, Boston University
>
> P.S. I know argv is var length, but that would be even harder to declare!

Yeah. C will only create hidden literals of type char array. Wouldn't it
be nice to use expressions like `intptr = &2;' instead of the more
readable & nonportable `intptr = "\2\0\0\0";' (VAX) :-) Seriously tho,
remember DEC Fortran's `vectored arrays'? Why not get rid of `real'
arrays as well, & make them all pointers. When we declare:

                int     array[3][5];

let's really let the compiler do:

                int     ??[15];
                int     *?[3] = { ?? + 0, ?? + 5, ?? + 10};
                int     **array = ?;

where `?' & `??' are invisible `names' known only to the compiler.
Forgive me if I got the subscripts backwards. This would lose for one
dimensional arrays & constant references to multidimensional arrays, but
gain speed on random refs to multiple arrays. The extra space is the
price one pays for consistancy. Or maybe only higher dimension arrays
should be vectored. To gain vectoring one would tack on `[1]' to an
array name or use the (nonexistent) keyword `vectored'. Or maybe nobody
cares. Just idle thoughts.

        jim             cottrell@nbs
*/
------
(Mail) End of article 4939 (of 4956)--what next? [npq]

Article 4940 (16 more) in net.lang.c:
From: [e-mail] (COTTRELL, JAMES)
Subject: No Such Thing
Message-ID: <[e-mail]>
Date: 29 Aug 85 20:48:56 GMT
Date-Received: 2 Sep 85 06:59:23 GMT
Sender: [e-mail]
Lines: 124

--MORE--(9%)/*
> From: Mike (I'll be mellow when I'm dead) Meyer <[e-mail]>

That's MY slogan too.

> In [e-mail] jim cottrell ([e-mail]) says:
> > Flame On! THERE IS NO SUCH THING AS A BOOLEAN!!! Flame Off.
>
> :-) Ok, we now know that jim doesn't believe in true and false. Does
> he drop right and wrong at the same time? How about write and read? :-)

Cute.

> > In case you hadn't noticed, `<' & company are infix operator that
> > return a constant `zero' or `one'. Thus, *every* conditional using
> > the `boolean' operators ultimately reduces to either
> >     if (0) { ... }          or      if (1) { ... }
> > THIS IS NOT A KLUDGE! It is the WAY IT SHOULD BE! What could be
> > more mnemonic (except to a nihilist :-) than TRUE if nonzero, and
> > FALSE if zero. One of C's design virtues is that it is minimal, yet
> > (relatively) complete. Don't drag outmoded concepts into the future!
>
> TRUE if nonzero, FALSE if zero? Sounds like jim just built a map from
> the set of C integers to booleans. But booleans don't exist, so such a
> map can't exist. Maybe what jim meant was:
>       if (expression) { ... }
> is the same as:
>       if expression is non-zero then { ... }.

That's what the book says.

> BTW, for something more mnemonic that
>       0 -> FALSE, {x | x /= 0} -> TRUE,
> how about
>       nil -> FALSE, {x | x /= nil} -> TRUE, or
>       {x | x = 0 mod 2} -> TRUE, {x | x = 1 mod 2} -> FALSE?

As for the first, sounds like LISP. Are you proposing a funny predefined
`thing' called `nil' that points to itself like in LISP? Will we have
to cast all our tests to the proper type?

As for the first, sounds like VAX Fortran. Since the VAX is
little-endian, the low bit test words on all LOGICAL*[124] types.

There have been all sorts of true-false mappings & conventions. Let's
not forget using the sign bit. Anyway, to my mind, (& evidently to
K&R) the use of zero to represent false is the most reasonable
thing to do, if restricted to *in-band* values. When you ain't
got nothin', you got nothin' to lose.

> Second BTW: C is not minimal. It's not bad, but there a half-dozen or
> so languages that have fewer operators, and equivalent completeness.
> Most of those are harder to use than C, though.

Okay. What I mean by minimal is that it includes only those features
truly necessary to fully describe an idealized portable machine and
which have meaning to the compiler. There is no exponentiation because
few (if any) machines have it as a primitive. There is no repeat-until
statement because that is a trivial variation of a while. There is no
I/O, sets, booleans, complex numbers, or inline functions (except
sizeof) that most other general purpose languages have.

> > > Many Boolean expressions are not best thought of as comparison of
> > > an arithmetic quantity against zero.  For example:
> > >   while ( ! Done() )
> > >           Perform_Action();
> >
> > We agree, but for different reasons. You insist on dragging in
> > an outmoded concept, then complaining that it doesn't fit very well.
> > I just read what it says.
>
> Sorry, but you've got it backwards. He's trying to pull a modern
> concept (TRUTH :-) into an obsolete language. Of course, if your
> language is nothing more than a high-level assembler, then using the
> funny "zero is false" map is ok, providing the underlying hardware
> doesn't provide a boolean type of it's own.

Like What? Zero is the most unique & important constant in the universe!
All (or 99.99%) machines have a branch on (non)zero & some even have
clear instruxions.

> > > I am pretty conservative
> >
> > I think this pretty much sums it up.
>
> Yeah - somebody who expects the programming languages to make their
> job easier is pretty conservative. I'm that way to - I want a language
> that makes it easy to turn my thoughts into code. This is why I prefer
> ALGOLW or C to FORTRAN or BASIC, and CLU or LISP to ALGOLW or C.

Why do you keep putting a `W' on the end of `ALGOL'? I haven't a CLU :-)

> > Actually, Doug, I'm not so much writing this to you as much as
> > all those other people out there who insist on fortrash as a model
> > for all their computing. Sorry about the cheap shot, but I wish you
> > were a little more daring in your philosophy. K & R were.
>
> Sorry, but I can't resist: Jim, from where I stand, *you* insist on
> fortrash as a model for your computing. There are more similarities
> between C and fortrash than differences. The C "if x is zero then ..."
> reminds me of the fortrash arithmetic if. But further discussion
> belongs in net.lang.*

Twisting things around a bit aren't we? I never even used the
arithmatic if except when I was a freshman & thought it was cute.
There are two main features of a language as I see it: 1) control
struxures, & 2) data struxures. Fortran 77 has matured somewhat in
the former, but leaves a lot to be desired in the latter.

>       <mike
>
> "Truth is variable."
>
> * disclaimer: I like C. It's easily the best language to come out of
> the early '70s I've seen. However, this does not imply that 1) it's
> perfect; or 2) there aren't better general purpose languages
> available.

1) Agreed. I have criticized C as well in this very forum.
2) Maybe so. But *widely* available?

        jim             cottrell@nbs
*/
------
(Mail) End of article 4940 (of 4956)--what next? [npq]

Article 4941 (15 more) in net.lang.c:
From: [e-mail] (COTTRELL, JAMES)
Subject: No Such Thing
Message-ID: <[e-mail]>
Date: 29 Aug 85 23:56:53 GMT
Date-Received: 2 Sep 85 07:03:41 GMT
Sender: [e-mail]
Lines: 11

--MORE--(64%)/*
> I don't understand the point of explaining how C maps
> natural booleans into arithmetic terms; that is just
> what I am complaining about.

Does anyone else besides Gwyn have trouble with mapping booleans to integers?
(Sorry Doug, I just couldn't resist :-)

        jim             cottrell@nbs
*/
------
(Mail) End of article 4941 (of 4956)--what next? [npq]

Article 4942 (14 more) in net.lang.c:
From: [e-mail] (Mark Purtill)
Subject: Re(n): null loop bodies
Message-ID: <[e-mail]>
Date: 30 Aug 85 00:12:41 GMT
Date-Received: 2 Sep 85 07:03:58 GMT
Sender: [e-mail]
Lines: 17

--MORE--(61%)<Fnord>
I use either:

          while (test ) ; /* no body! */

or

          while (test ) {
                    ;
                    }

depending on space (on the screen) considerations.  Or at least I ought
to.

       Mark
^.-.^  Purtill at MIT-MULTICS.ARPA    **Insert favorite disclaimer here**
(("))  2-032 MIT Cambrige MA 02139
(Mail) End of article 4942 (of 4956)--what next? [npq]

Article 4943 (13 more) in net.lang.c:
From: [e-mail] (Bill Crews)
Subject: Re: "handy.h"
Message-ID: <[e-mail]>
Date: 30 Aug 85 15:02:54 GMT
Date-Received: 2 Sep 85 07:19:58 GMT
References: <[e-mail]>
Organization: Cyb Systems, Austin, TX
Lines: 17

--MORE--(50%)>
> I'm interested in coming up with an include file, say "handy.h",
>
> -- Rich Wagner

If people, when choosing names for functions, variables, files, etc, would
think at least briefly about what name would be the most meaningful to an
uninitiated reader, we readers would have a much easier time.  I would
suggest you come up with names like types.h or ctlchars.h or whatever,
segregate them functionally and name them appropriately.

--
  /  \    Bill Crews
 ( bc )   Cyb Systems, Inc
  \__/    Austin, Texas

[ gatech | ihnp4 | nbires | seismo | ucbvax ] ! ut-sally ! cyb-eng ! bc
(Mail) End of article 4943 (of 4956)--what next? [npq]

Article 4944 (12 more) in net.lang.c:
From: jeff@isi-vaxa (Jeffery A. Cavallaro)
Subject: Re: \"handy.h\"
Message-ID: <[e-mail]>
Date: 30 Aug 85 16:48:17 GMT
Date-Received: 2 Sep 85 07:20:52 GMT
Sender: [e-mail]
Lines: 12

--MORE--(53%)Well, for starters you should take a look at the specification for the
portability definition file "stdtype.h" described in the PLUM HALL
document "C PROGRAMMING STANDARDS AND GUIDELINES".  The latest version I
have is JAN-1982, edition 3.  In this addition, stdtype is described in
section 1.3.  Every site should have a version for each particular
machine type.

In addition, I would suggest the following:

#define         FALSE           0
#define         TRUE            1
#define         EOL             '\0'            /* End-of-line */
(Mail) End of article 4944 (of 4956)--what next? [npq]

Article 4945 (11 more) in net.lang.c:
From: [e-mail] (Jeffery A. Cavallaro)
Subject: Re: \"handy.h\"
Message-ID: <[e-mail]>
Date: 30 Aug 85 17:29:54 GMT
Date-Received: 2 Sep 85 07:21:07 GMT
Sender: [e-mail]
Lines: 12

--MORE--(53%)Well, for starters you should take a look at the specification for the
portability definition file "stdtype.h" described in the PLUM HALL
document "C PROGRAMMING STANDARDS AND GUIDELINES".  The latest version I
have is JAN-1982, edition 3.  In this addition, stdtype is described in
section 1.3.  Every site should have a version for each particular
machine type.

In addition, I would suggest the following:

#define         FALSE           0
#define         TRUE            1
#define         EOL             '\0'            /* End-of-line */
(Mail) End of article 4945 (of 4956)--what next? [npq]

Article 4946 (10 more) in net.lang.c:
From: [e-mail] (Richard Welty)
Subject: Re: Re: Re: C bites (Null loop-bodies)
Message-ID: <[e-mail]>
Date: 31 Aug 85 00:18:52 GMT
Date-Received: 2 Sep 85 08:18:51 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: net
Organization: RPI CS Department, Troy  NY
Lines: 37

--MORE--(42%)> >     I put null loop-bodies on a separate line like in the following
> > example.
> >
> >             while (eatup() != '\n')
> >                     ;
>
> Putting the semi-colon on a separate line does help make it clear
> that the body of the loop is intentionally null, but what I like
> even better is:
>
>               while( eatup() != '\n' )
>                       continue;
>
I personally like to use {} in all cases ... thus:

        while( eatup() != '\n'){}
or
        while( eatup() != '\n')
            {}
or even
        while( eatup() != '\n')
        {
        }
By using the {} all the time, even for null cases, I insure
that things like
        if( cond);
don't happen ...
--
                                Rich Welty

        (I am both a part-time grad student at RPI and a full-time
         employee of a local CAE firm, and opinions expressed herein
         have nothing to do with anything at all)

        CSNet:   weltyrp@rpi
        ArpaNet: weltyrp.rpi@csnet-relay
        UUCP:  seismo!rpics!weltyrp
(Mail) End of article 4946 (of 4956)--what next? [npq]

Article 4947 (9 more) in net.lang.c:
From: [e-mail] (David Eppstein)
Subject: Re: Re: c programming style - READ THIS
Message-ID: <[e-mail]>
Date: 31 Aug 85 18:38:03 GMT
Date-Received: 2 Sep 85 08:19:10 GMT
References: <[e-mail]> <[e-mail]>
Reply-To: [e-mail] (David Eppstein)
Organization: Columbia University
Lines: 25

--MORE--(31%)In article <[e-mail]> [e-mail] writes:
>
> Since 'p+n', where p is a pointer and n is an integer, is equivalent to
> adding n*sizeof(whatever p points to), the safe and portable way of adding
> an integer to a pointer treated as an integer is
>        (char *)p + n
> since (I think) character are always a byte wide.  If that's not always the
> case, I apologize; on the other hand, it's probably safe than converting
> a pointer to an int or a long;  I had trouble porting something from a VAX
> to a Pyramid because of a cast of this sort.

Not the case.  For instance on the DEC-20, adding integers to (int *)
looks like adding integers to integers but adding them to (char *)
does something totally different (divides by number of bytes per word,
adds word quotient as an integer, adds number of bytes remainder
multiplied by byte size shifted over by 30 bits; bytes per word and
bits per byte have to be calculated from the pointer itself because
we have both 7-bit bytes packed 5 to a word and 9-bit bytes packed
4 to a word (others too but those are the ones used in C); this is not
as bad as it sounds because there is a machine instruction to do it all).

On all implementations that I know about, coercing the pointer to (long) and
adding your integer will work.  However this is still somewhat nonportable
and you are better off doing whatever you are trying to do some other,
clean, portable way not involving adding integers as integers to pointers.
(Mail) End of article 4947 (of 4956)--what next? [npq]

Article 4948 (8 more) in net.lang.c:
From: [e-mail] (Dick Dunn)
Subject: Re: Cryptic C (enum as boolean type)
Message-ID: <[e-mail]>
Date: 30 Aug 85 05:02:04 GMT
Date-Received: 2 Sep 85 08:30:59 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: NBI,Inc, Boulder CO
Lines: 16

--MORE--(45%)> Instead of using #defines for the boolean values, I
> would rather see enumerated data types used.  In general,
> C programmers seem to prefer #defines to defining a data
> type that can be checked during compilation.
>
>       typedef enum { False , True } Boolean;

Whether this works depends on your compiler's view of enums.  If it treats
enums as a slight variant on integers (which to my tastes is pretty
sloppy), you're OK.  However, if it uses the very restricted view which
doesn't allow arithmetic on enums, the above definition will prevent the
"usual" logical operators !, &, ^, and | from working with objects of type
Boolean.
--
Dick Dunn       {hao,ucbvax,allegra}!nbires!rcd         [phone] x3086
   ...Relax...don't worry...have a homebrew.
(Mail) End of article 4948 (of 4956)--what next? [npq]

Article 4949 (7 more) in net.lang.c:
From: [e-mail]
Subject: Re: Re: how has C bitten you?  (Really,
Message-ID: <[e-mail]>
Date: 29 Aug 85 02:52:00 GMT
Date-Received: 3 Sep 85 04:00:53 GMT
References: <[e-mail]>
Lines: 24

--MORE--(31%)
>>Gee....and I thought a zero pointer was guaranteed not to point to
>>anything valid (K&R says this).

>All valid implementations of C guarantee this.  Obviously, the
>implementation of C that this was done on is not valid.  He should complain
>to the vendor.  (Yes, there have been such implementations; one well-known
>chip maker's first UNIX release didn't put the necessary shim at data
>location 0 on a separate I&D space program.  They fixed it shortly
>afterwards.)

Speaking of issues that have been beaten to death!  K&R says only that the
value 0 is distinguishable from pointers that point to objects, and that
therefore the value zero is not a "valid" pointer.  It certainly does not
say that the 0 pointer will give you the "null" or empty value of any
object, and in particular it does not promise that there will be an integer
zero if you dereference (int*)0, or a character zero if you dereference
(char*)0, nor a memory fault if you reference (foo*)0.

NO, you cannot depend upon the value obtained by dereferencing ANY pointer
that has been assigned the value zero.  It does not point to any object;
the implementation of C does not guarantee  to protect you from erroneously
trying to access that object and the result is unpredictable over various
implementations.
(Mail) End of article 4949 (of 4956)--what next? [npq]

Article 4950 (6 more) in net.lang.c:
From: [e-mail]
Subject: Re: Re: how has C bitten you?  (Really,
Message-ID: <[e-mail]>
Date: 29 Aug 85 13:48:00 GMT
Date-Received: 3 Sep 85 04:01:11 GMT
References: <[e-mail]>
Lines: 19

--MORE--(40%)
[]

One final, subtle, point.  K&R does not guarantee that the *value* 0 is
distinguishable from all other pointers, but rather, that the *constant* 0
is.  That is to say, you may compare against 0 to determine the validity of
a pointer (or assign to guarantee invalidity), but you may not assume that
comparison against (or assignment of) an int variable whose value is 0 will
have the same result.  This picky distinction probably doesn't affect any
of the better known chips, but might be important on a machine where a null
pointer is not a bit string of 0s.

            --Darryl Richman, INTERACTIVE Systems Corp.
            ...!cca!ima!ism780!darryl
            The views expressed above are my opinions only.

P.S.:  I know that this sounds amazing, so look at the top of K&R p190,
under the section 7.7, equality operators (second paragraph), and again
on top of p192, section 7.14, assignment operators.
(Mail) End of article 4950 (of 4956)--what next? [npq]

Article 4951 (5 more) in net.lang.c:
From: [e-mail]
Subject: "handy.h"
Message-ID: <[e-mail]>
Date: 28 Aug 85 14:39:00 GMT
Date-Received: 3 Sep 85 04:01:19 GMT
Lines: 16

--MORE--(52%)
I'm interested in coming up with an include file, say "handy.h",
which declares a lot of commonly useful "stuff".  A lot of discussion
(an AWFUL lot) has been going on about Boolean typedefs/defines --
that's the sort of thing I'm looking for:

    typedef enum { false, true } bool;

Other plausible candidates for this "second stdio.h" might be:

    typedef char *string;
    #define FORMFEED '\014'      /*  ASCII form feed  */

Any other suggestions would be appreciated.

-- Rich Wagner
(Mail) End of article 4951 (of 4956)--what next? [npq]


Article 4954 (2 more) in net.lang.c:
From: [e-mail] (Peter da Silva)
Subject: Re: \"handy.h\"
Message-ID: <[e-mail]>
Date: 31 Aug 85 14:40:13 GMT
Date-Received: 3 Sep 85 05:21:58 GMT
References: <[e-mail]>
Organization: The Power Elite, Houston, TX
Lines: 8

--MORE--(78%)> #define               FALSE           0
> #define               TRUE            1
> #define               EOL             '\0'            /* End-of-line */

#define EOL '\n'
#define EOS '\0'

... unless, of course, you're on a really weird O/S.
(Mail) End of article 4954 (of 4956)--what next? [npq]

Article 4955 (1 more) in net.lang.c:
From: [e-mail] (Doug Pardee)
Subject: Numeric comparisons
Message-ID: <[e-mail]>
Date: 30 Aug 85 18:29:16 GMT
Date-Received: 3 Sep 85 06:13:03 GMT
References: <[e-mail]> <[e-mail]>
Organization: Calcomp Display Products Division, Scottsdale, AZ, USA
Lines: 24

--MORE--(41%)> ... since comparison is merely done by subtraction (a
> compare instruction is usually just a subtract instruction that doesn't
> store the result anywhere)...

Compiler writers note -- a comparison is not "just a subtract".
For example:

#define NBITS 16
/* NBITS is number of bits in an integer */
   int a, b;
   a = 3 << (NBITS-3);  /* 24576 for NBITS=16 */
   b = -a;
   if (a>b)
      printf("Comparison was done by bit-wise comparison\n");
   else
      printf("Comparison was done by subtraction\n");   /* WRONG */

Compiler users note -- if your compiler gives the wrong results, the
compiler writer might not be completely at fault.  Many early CPU
chips (8080A, Z80, 6502, etc.) did comparison by subtraction, and a
compiler would have had to generate extra code to test for Overflow
in order to get the correct result.
--
Doug Pardee -- CalComp -- {seismo!noao,decvax!noao,ihnp4}!terak!doug
(Mail) End of article 4955 (of 4956)--what next? [npq]

Article 4956 in net.lang.c:
From: [e-mail] (Andrew Koenig)
Subject: Re: Re: how has C bitten you?  (Really,
Message-ID: <[e-mail]>
Date: 30 Aug 85 16:04:11 GMT
Date-Received: 4 Sep 85 05:53:32 GMT
References: <[e-mail]>
Organization: Bell Labs, Murray Hill
Lines: 27

--MORE--(25%)>>All valid implementations of C guarantee this.  Obviously, the
>>implementation of C that this was done on is not valid.  He should complain
>>to the vendor.  (Yes, there have been such implementations; one well-known
>>chip maker's first UNIX release didn't put the necessary shim at data
>>location 0 on a separate I&D space program.  They fixed it shortly
>>afterwards.)

>Speaking of issues that have been beaten to death!  K&R says only that the
>value 0 is distinguishable from pointers that point to objects, and that
>therefore the value zero is not a "valid" pointer.  It certainly does not
>say that the 0 pointer will give you the "null" or empty value of any
>object, and in particular it does not promise that there will be an integer
>zero if you dereference (int*)0, or a character zero if you dereference
>(char*)0, nor a memory fault if you reference (foo*)0.

>NO, you cannot depend upon the value obtained by dereferencing ANY pointer
>that has been assigned the value zero.  It does not point to any object;
>the implementation of C does not guarantee  to protect you from erroneously
>trying to access that object and the result is unpredictable over various
>implementations.

I think the "necessary shim" referred to in the first note quoted
above has nothing to do with a value intended to ensure that *(int*)0
give a defined value.  Rather, it is a dummy variable located at
location 0 designed to ensure the NOTHING ELSE find itself at location
0 by accident!  The trouble with putting a variable at location 0
is that its address will then erroneously appear to be NULL.
(Mail) End of article 4956 (of 4956)--what next? [npq]

End of newsgroup net.lang.c.